i64 to BigInt in JS #1172
Comments
|
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? |
Yes, that's my idea.
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. |
|
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). |
|
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. |
With this patch, BigInts have support for bidirectionally converting to 64-bit integer WebAssembly values, which appears as - Parameters and return values to exported WebAssembly functions - Parameters and return values to host functions - Imported and exported globals BigInts can be read or written from WebAssembly memory using the BigInt proposal's BigInt64Array or BigUint64Array; no additional support is needed. This patch includes basic conformance tests in jsapi.js, which tests that the conversion is done properly in the six cases listed above. I don't know of any Wasm implementation that attempts to implement this specification, so I converted most of the test to be against i32 and saw that converted version pass on V8 (this process helped work out a few silly test bugs). Closes WebAssembly/design#1172
With this patch, BigInts have support for bidirectionally converting to 64-bit integer WebAssembly values, which appears as - Parameters and return values to exported WebAssembly functions - Parameters and return values to host functions - Imported and exported globals BigInts can be read or written from WebAssembly memory using the BigInt proposal's BigInt64Array or BigUint64Array; no additional support is needed. This patch includes basic conformance tests in jsapi.js, which tests that the conversion is done properly in the six cases listed above. I don't know of any Wasm implementation that attempts to implement this specification, so I converted most of the test to be against i32 and saw that converted version pass on V8 (this process helped work out a few silly test bugs). Closes WebAssembly/design#1172
With this patch, BigInts have support for bidirectionally converting to 64-bit integer WebAssembly values, which appears as - Parameters and return values to exported WebAssembly functions - Parameters and return values to host functions - Imported and exported globals BigInts can be read or written from WebAssembly memory using the BigInt proposal's BigInt64Array or BigUint64Array; no additional support is needed. This patch includes basic conformance tests in jsapi.js, which tests that the conversion is done properly in the six cases listed above. I don't know of any Wasm implementation that attempts to implement this specification, so I converted most of the test to be against i32 and saw that converted version pass on V8 (this process helped work out a few silly test bugs). Closes WebAssembly/design#1172 Co-authored-by: Daniel Ehrenberg <littledan@chromium.org>
|
This issue is now a proposal thanks to @littledan |
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:
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?
The text was updated successfully, but these errors were encountered: