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
With the JS String Builtins proposal having been stabilized in Chrome and soon stabilizing in Firefox, it would be a great idea to start supporting it from wasm-bindgen. Most importantly I think it would be great to be able to directly import JsString literals directly from the browser without having to run any code to do the UTF-8 to UTF-16 conversion at all.
Proposed Solution
Provide a macro js_sys::string! macro that can be used like so:
string!("Hello, World!")
this expands to an internal wasm-bindgen machinery similar to describe which wasm-bindgen's CLI can then interpret and transform into an imported externref like so:
a fallback to constructing the JsString at runtime should be available in case the feature is disabled in wasm-bindgen.
Alternatives
One alternative would be to not make use of the proposal at all and instead simply generate the literals into the __wbindgen_init_externref_table function where other types of literals could even be supported such as BigInt literals. This would also directly put the literals at a constant index of the externref table, whereas the proposal will give us a global which would need to be placed in the table at runtime.
Additional Context
None yet
The text was updated successfully, but these errors were encountered:
Motivation
With the JS String Builtins proposal having been stabilized in Chrome and soon stabilizing in Firefox, it would be a great idea to start supporting it from
wasm-bindgen
. Most importantly I think it would be great to be able to directly importJsString
literals directly from the browser without having to run any code to do the UTF-8 to UTF-16 conversion at all.Proposed Solution
Provide a macro
js_sys::string!
macro that can be used like so:this expands to an internal
wasm-bindgen
machinery similar todescribe
whichwasm-bindgen
's CLI can then interpret and transform into an importedexternref
like so:a fallback to constructing the
JsString
at runtime should be available in case the feature is disabled inwasm-bindgen
.Alternatives
One alternative would be to not make use of the proposal at all and instead simply generate the literals into the
__wbindgen_init_externref_table
function where other types of literals could even be supported such asBigInt
literals. This would also directly put the literals at a constant index of theexternref
table, whereas the proposal will give us a global which would need to be placed in the table at runtime.Additional Context
None yet
The text was updated successfully, but these errors were encountered: