Closed kevinbarabash closed 5 years ago
Not in the current proposal. The n
is a bit redundant, in my opinion. Do you think it should be permitted?
If the n
is redundant does that mean _px
stores the number internally as a BigInt?
No, it passes both a String and Number representation to _px
So 9007199254740991_px
would result in an object with a truncated .number
field, but the .string
field would be 9007199254740991
.
@kevinbarabash These functions can do anything. They don't simply return their argument. One thing it may do is parse the string
given to it as a BigInt and return that.
I see... an object with .string
and .number
is passed to _px
but _px
could return anything. Thanks for helping me understand.
OK, seems like the question has been answered, so closing the issue.
I curious why it wouldn't just pass the string what is the point in passing the number?
On Sat, Sep 22, 2018 at 1:37 PM Daniel Ehrenberg notifications@github.com wrote:
Closed #18 https://github.com/tc39/proposal-extended-numeric-literals/issues/18.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-extended-numeric-literals/issues/18#event-1861745446, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMDKuvp2SOzz6aK1dQhB-UGkcjM1Ur5ks5udp9wgaJpZM4WtHTh .
Probably just convenience since most uses would probably just pass the string to parseInt
anyway.
Performance, to avoid reparsing in the common case. (You can cache on the object with a WeakMap, but this has its own performance cost.)
Would
const a = 9007199254740991n_px
be allow?