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.

[guybedford]

I have been tentatively considering using wasm-js: here for things which are "JS conventions" and not actually even builtins.

That is - in the (unlanded) phase integration proposal (#117) I was using wasm-js:phase/foo to indicate a phase import in the second-level import string as a special reserved string that doesn't imply a builtin but rather implies a JS convention, separate from wasm:js-string providing an actual builtin.

For the string constant here, then thinking of the string constant less of a builtin itself and more of a naming convention such that wasm-js: might make sense.

In this framing:

• wasm: formally specified builtins within Wasm specs
• wasm-js: ESM-integration or JS-API specific conventions only.

For example (and certainly not proposing it now), we might also imagine some hypothetical future wasm-js:global/WebAssembly to get an externref for the WebAssembly global say.

Maybe this framing doesn't make sense though and I'm also completely fine with dropping this idea though and just going with wasm:js-string/constants too, but since we had wasm-js and while we're doing the bikeshed let's do it well I guess.

As for wasm:js/, wasm:component/, wasm:python/ style builtin structuring, that seems othogonal to these convention considerations and absolutely fine to me as well.

My preference would be pretty much equal between say wasm-js:string-constants or wasm:js-string/constants though.

[lukewagner]

@eqrion That's a good point about the proliferation of wasm-${X}: schemes; wasm:${X}/ seems like a totally reasonable alternative.

[eqrion]

@guybedford I don't think we need to use the scheme to make a distinction between 'JS builtins' and 'JS conventions'. For the phase example you could use wasm:js/phase/source just as well.

I think my preference going forward would be for everything defined in the wasm spec or wasm embedder specs (like the JS-API) to use the plain wasm: scheme, and then group all embedder specific things into a single path. Any core wasm feature usable for all embedders could claim something in the root path.

So we would have:

// js-string-builtins
wasm:js/string
wasm:js/string-constants

// js-primitive-builtins
wasm:js/number
wasm:js/boolean
...

// custom-descriptors
wasm:js/prototypes

cc @tlively as someone working on something that uses the wasm scheme.

[guybedford]

Sure, agreed with aligning on wasm: here then and avoiding wasm-js: for now. Let's please ensure wasm:js/string-constants is an exception to most other builtins though in using a kebab name, to rather prefer hierarchical wasm:js/string/feature style imports for sub modules for most situations.

Given the above, will we want to go through the re-aliasing process here on the builtins proposals into wasm:js/? Primitive builtins can likely be updated in the proposal, but string builtins would require a PR at this point?

I've updated the PR in #115, would value a review there.

[tlively]

cc @tlively as someone working on something that uses the wasm scheme.

I'm happy with anything. Settling on wasm:a/b... for everything sounds fine. Having to add aliases for the existing builtins is a little unfortunate, but well worth it to have a settled convention everyone is happy with using going forward.

[eqrion]

Sure, agreed with aligning on wasm: here then and avoiding wasm-js: for now. Let's please ensure wasm:js/string-constants is an exception to most other builtins though in using a kebab name, to rather prefer hierarchical wasm:js/string/feature style imports for sub modules for most situations

Ah, I wasn't really thinking of string constants as a 'sub module', but that makes sense to me. I'd be happy to go with wasm:js/string/constants too.

@tlively

Having to add aliases for the existing builtins is a little unfortunate, but well worth it to have a settled convention everyone is happy with using going forward.

Yeah, agreed it's not ideal. It's currently just a single mapping for wasm:js-string to wasm:js/string` so it's hopefully not too disruptive.