Bug 287402 – WasmGC support for `js-string` builtin proposal

• Status: NEW
• Component: WebAssembly

[Martin Kustermann]

For any language compiling to WasmGC instead of JavaScript, operations on JS strings is crucial and the `js-string` builtin proposal is a step in this direction by providing a standardized interface for JS string operations that can be optimized by implementors as well as by providing a good way to import JS string constants.

The `js-string` builtin (**) proposal has been effectively finalized and is implemented and enabled on Chrome & Firefox. It would be nice to also get this implemented in WebKit.

One cannot entirely polyfill the `js-string` builtins: One can polyfill the imported JS string functions from the proposal, but not the import of string constants (as the actual string constants are utf8-encoded in the wasm module encoding of the imports - instead of using the import tables, see (***)).

(**) https://github.com/WebAssembly/js-string-builtins
(***) https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md#string-constants

[Radar WebKit Bug Importer]

<rdar://problem/144981609>

In Kotlin, we would love to see support for this proposal.

Actually, I think any language targeting WasmGC on the web would also like to use this proposal and benefit from it.

[Martin Kustermann]

Sidenote:

> One cannot entirely polyfill the `js-string` builtins: One can polyfill the imported JS string functions from the proposal, but not the import of string constants (as the actual string constants are utf8-encoded in the wasm module encoding of the imports - instead of using the import tables, see (***)).

As was pointed out to me, it is actually possible to polyfill the import of string constants by utilizing a JS Proxy object that intercepts the import lookups and just returns the property name (which is the actual string constant).

```
      S: new Proxy({}, { get(_, prop) { return prop; } }),
```