You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm requesting a TAG review of JS String Builtins for WebAssembly.
JavaScript runtimes have a rich set of builtin objects and primitives. Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation. The most pressing use-case here is for languages who would like to use the JavaScript String type to implement their strings. This proposal aims to provide a minimal and general mechanism for importing specific JavaScript primitives for efficient usage in WebAssembly code.
This is done by first adding a set of wasm builtin functions for performing JavaScript String operations. These builtin functions mirror a subset of the JavaScript String API and adapt it to be efficiently callable without JavaScript glue code. Then a mechanism for importing these wasm builtin functions is added to the WebAssembly JS-API. These two pieces in combination allow runtimes to reliably emit optimal code sequences for JavaScript String operations within WebAssembly modules. In the future, other JS builtin objects or JS primitives can be exposed through new wasm builtins.
Relevant time constraints or deadlines: Planning to move to Phase 3 by June 2024
The group where the work on this specification is currently being done: WebAssembly Community Group
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WebAssembly Working Group
Major unresolved issues with or opposition to this specification: N/A
This work is being funded by: Mozilla, Google
You should also know that...
The current design is a result of extensive discussion in the Wasm CG over the past year (see above meeting notes), and follows a previous approach to dealing with strings directly in core Wasm, https://github.com/WebAssembly/stringref, which faced significant opposition in the CG.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify eqrion and ajklein
The text was updated successfully, but these errors were encountered:
Bloomberg previously sponsored work towards the WebAssembly stringref proposal. At this point, we aren’t pushing for one alternative over another. I am just happy to see something moving forward for zero-copy strings in WebAssembly.
こんにちは TAG-さん!
I'm requesting a TAG review of JS String Builtins for WebAssembly.
JavaScript runtimes have a rich set of builtin objects and primitives. Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation. The most pressing use-case here is for languages who would like to use the JavaScript String type to implement their strings. This proposal aims to provide a minimal and general mechanism for importing specific JavaScript primitives for efficient usage in WebAssembly code.
This is done by first adding a set of wasm builtin functions for performing JavaScript String operations. These builtin functions mirror a subset of the JavaScript String API and adapt it to be efficiently callable without JavaScript glue code. Then a mechanism for importing these wasm builtin functions is added to the WebAssembly JS-API. These two pieces in combination allow runtimes to reliably emit optimal code sequences for JavaScript String operations within WebAssembly modules. In the future, other JS builtin objects or JS primitives can be exposed through new wasm builtins.
Further details:
You should also know that...
The current design is a result of extensive discussion in the Wasm CG over the past year (see above meeting notes), and follows a previous approach to dealing with strings directly in core Wasm, https://github.com/WebAssembly/stringref, which faced significant opposition in the CG.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify eqrion and ajklein
The text was updated successfully, but these errors were encountered: