i64 to BigInt in JS

[xtuc]

Currently I64 can't pass the boundaries of WebAssembly, it will throw an exception from the Hostfunc. BigInt was already mentioned in some issues in the WebAssembly organization, but not exactly for what I mean here.

Today V8 announced the support for the BigInt proposal (still stage 3 at the moment), we can expect to see more and more adoption soon.

My idea is:

• if the host support BigInt we can safely convert the i64 value into a BigInt value.
• If not, it would throw.

This introduces an inconsistent behavior on some hosts, but avoiding that would lock down i64 in JS for a very long time.

What do you think?

[rossberg]

It is the current plan of record to reflect i64 as BigInt once it is standard in JS. Are you suggesting to start doing so earlier? If so, what's benefit if it's not portable?

[xtuc]

Are you suggesting to start doing so earlier?

Yes, that's my idea.

If so, what's benefit if it's not portable?

Since we don't have a wide adoption for BigInt anyway, the use case might be to restricted at the moment.

But to make it portable we would have a mechanism to allow the user to fallback to something else, otherwise he will probably implement his own mechanism. It will be then very difficult for WebAssembly to introduce a breaking change.

[littledan]

One possibility would be to prepare the WebAssembly/BigInt interaction so that it's possible for browsers to ship the WebAssembly BigInt integration at the same time as they ship BigInt itself. I could write a specification for this. I'm not sure if we should throw an exception or not for out-of-bounds BigInts; maybe we should be consistent with TypedArrays (which would not throw).

[xtuc]

Thinking about this a bit more. Since you can share a chunk of memory between the module instance and JavaScript you could use it to grab the i64 value (and use BigInt).

That is more a workaround than a real solution.

[xtuc]

This issue is now a proposal thanks to @littledan