BigInt for i64 and larger?

[Desdaemon]

An interesting tidbit I came across while implementing glue code for wasm_bindgen is that it translates integer types larger than 32 bits to be BigInt, with no way to opt out AFAIK. This makes sense more on the web as DartJS integers are limited in their representations (from -2^53 + 1 to 2^53 - 1). So there are two (+1) ways this can go:

• We follow suit and enforce uses of BigInt in user types, which would be a breaking change (worthy of a major version increase?), but this might be undesirable so we can keep it behind a flag and/or attributes.
• We don't implement this, and replace internal use of i64s to be i32s. This might be OK since the main usage of large integers is for pointers, and most WASM binaries are going to be 32-bit anyways.
• Highly unsound, but we allow JS numbers beyond the safe integer limit to be parsed as an i64 anyways, then i128 and u128 and be represented with BigInts.

Any thoughts?

[Desdaemon]

Another interesting solution is the fixnum library which unifies i64 representations across native and web, but this also falls into the first category of breaking changes.

[fzyzcjy]

Another interesting solution is the fixnum library

It reminds me that, google protobuf's dart/flutter implementation uses fixnum. And google protobuf also has 32bit as well as 64bit types. For 32bit it generates int, and for 64bit it generates fixnum.Int64.

worthy of a major version increase?

If web support is added, it sounds pretty acceptable to bump the major version. Indeed we may also create a reddit post or something like that to let people know it (especially people who originally came and left b/c they wanted web).

replace internal use of i64s to be i32s.

For "internal" I guess it is not a problem whether to use 32bit or 64bit, and this is not a breaking change - since it is used internally and users should not use them.

Highly unsound, but we allow JS numbers beyond the safe integer limit to be parsed as an i64 anyways

Agree it is "highly unsound" and dangerous ;)

So in short, I like the fixnum approach (and google protobuf also uses it).

[Desdaemon]

It reminds me that, google protobuf's dart/flutter implementation uses fixnum. And google protobuf also has 32bit as well as 64bit types. For 32bit it generates int, and for 64bit it generates fixnum.Int64.

That is certainly very interesting. I came to the same conclusion myself, but I'm glad there is some prior art to draw from.