currently unrepresentable numbers

[xtuc]

While I agree to specify the following types:

int64
uint64

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.

[Avol-V]

Big Int in Stage 3: https://github.com/tc39/proposal-bigint

[xtuc]

Yes I know, but the wording it a bit misleading IMO. I think that int64 or uint64 should be denoted as bigint.

[sirisian]

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.

[xtuc]

Note that currently the spec says: 2 ** 53 + 1 === 2 ** 53, I don't think we could implement the int64 easily and the bigInt proposal requires an explicit conversion.

[sirisian]

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.

[sirisian]

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.

[sirisian]

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.