String Constants Bikeshed

[guybedford]

As discussed at the CG meeting today, it might yet be possible to specify a string constant for the ESM Integration.

Opening the bikeshed here for the current main suggestions, which I believe are:

• wasm:js-string
• wasm-js:strings

The slide on this topic is here for more details on the discussion.

@eqrion please let me know if I've got this correct or if there are changes or other suggestions that should be considered.

@conrad-watt I believe you had some more thoughts here from the presentation.

Suggestions / feedback very much welcome.

[guybedford]

Cross-posting @lukewagner's comment from #115:

Just my 2c on wasm: vs wasm-js:: although longer, wasm-js is attractive since it makes it clear from both a JS/ESM and wasm perspective that we're talking about "JS built-ins exposed to wasm" and keeps wasm: open for hypothetical pure-wasm builtins as well as non-JS builtins exposed to wasm.

[eqrion]

To restate from the meeting, I originally had some hesitation around specifying the import name for string constants before we knew if the compact import section proposal would be standardized. If it is standardized, we want a pretty name here. But if it's not standardized, we'd want a short name for binary savings.

But I now think that one path forward would be to choose the longer prettier name now, and then consider adding an alias for a short name in a future where the CG rejects compact imports (if that happens).

So back to the question of what name to use.

We have precedence of using wasm:js-XYZ from the original js-string-builtins proposal. js-primitive-builtins is also using that format, but is in development and could be changed. If we choose a different format here, we should probably add an alias for js-string-builtins to match the new one.

@lukewagner I hear the concern about using the wasm: scheme for just 'pure-wasm' builtins. I'm not sure I like using wasm-js: though, because that doesn't seem scalable for future embedding specific builtin collections. Would we require component builtins to reserve their own scheme like wasm-component:? Or wasm-python:?

I wonder if we could use URL paths here and create a hierarchy to group builtins. So we could have wasm:js/string, and hypothetically wasm:component/ or wasm:python/. While still reserving the root paths for core wasm builtins.

Regardless of the scheme, I think the name should be something like string-constants. Which would give us either wasm:js-string-constants, wasm:js/string-constants, or wasm-js:/string-constants.

[sjrd]

We have precedence of using wasm:js-XYZ from the original js-string-builtins proposal. js-primitive-builtins is also using that format, but is in development and could be changed.

There's also custom descriptors, which defines wasm:js-prototypes.