-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
currently unrepresentable numbers #27
Comments
Big Int in Stage 3: https://github.com/tc39/proposal-bigint |
Yes I know, but the wording it a bit misleading IMO. I think that |
The goal with this proposal would be to implement all the types natively that don't exist. So if the proposal was included then int64 and uint64 would be representable. (There's a note in the spec changes about this here: https://github.com/sirisian/ecmascript-types#11831-static-semantics-mvs). You could write: let foo:uint64 = 18446744073709551615;
let bar:uint64 = 0xFFFFFFFFFFFFFFFF; How a dynamically typed variable would handle such a number is good question though that isn't covered yet in the proposal. So if you call foo(0xFFFFFFFFFFFFFFFF) what happens? It's clearly not a number. I would be inclined to say that it automatically uses uint64 transparently, but others might suggest that it throws a TypeError and requires explicit typing for such constants. |
Note that currently the spec says: |
I'm trying to design things such that literal suffixes aren't necessary. As an example I'd like this to work: let foo:uint64 = 9007199254740993 + 9007199254740992; // 18014398509481985 The last thing I'd want is to have to do: let foo:uint64 = uint64(9007199254740993) + uint64(9007199254740992); // 18014398509481985 If the language is setup in a way that it's forced to be let foo:uint64 = Number + Number; with no workaround that would be annoying. That might not be something that can be avoided though. let foo = 9007199254740993 + 9007199254740992; // 18014398509481984 I'm sure in the AST special rules could be designed to propagate type information to untyped literals. If this can be done to solve all the edge cases I'm unsure, but I'm thinking it could be. |
https://github.com/sirisian/ecmascript-types#expanding-representable-numbers I added a section to maybe prompt more discussion. I have no idea if what I wrote is possible. |
Fixed in: https://github.com/sirisian/ecmascript-types#type-propagation-to-literals I talked with someone more familiar with this, and it's possible. By propagating type information to literals (and arrays) it makes it so that literals are only treated as Number if they have any or Number type applied to them. |
While I agree to specify the following types:
They are not representable in JavaScript since numbers are 64 bits float (using the IEEE 754 standard).
What should be the behavior of the engine when handling values of that type? That might also confuse the user who annotated the value.
The text was updated successfully, but these errors were encountered: