String builtins merge, passing builtinSetNames and stringConstant

[guybedford]

With the spec now merged to the latest, we can explicitly integrate with the JS String Builtins proposal, passing the builtinSetNames and stringConstant parameters to module construction.

This explicitly now passes « "js-string" » for the builtinset.

For the string constant, I've added wasm-js:strings as the name for now, but this would benefit from some further discussion.

• Should we use a minimal string as previously discussed like $?
• If not, do we use wasm-js or wasm?
• Any other name suggestions / thoughts welcome.

Compression and optimized imports feel somewhat orthogonal to all this, but it might be worth having the conversation again.

We can leave out the string constant, but this seems like such a useful feature that it would be really nice if we could figure out if there's an approach that can work here.

// cc @eqrion

[eqrion]

@guybedford Overall LGTM. I'm uncertain about the string constants import though.

I think we'd be unhappy if we were always stuck with wasm-js:strings (a verbose name) and also compact-imports is not standardized. I'd also think we'd be unhappy if we were always stuck with a short non-descriptive name like $ and compact-imports was standardized.

My understanding is that not picking a name for string constants now doesn't preclude us from picking one later? So could we continue to defer the question? I know I've not made any progress on compact-imports recently, but I do hope to pick it up soon. I think if that moves to phase 2 we'll have more clarity here.

[guybedford]

@eqrion thanks for taking a look here.

I wonder if compact imports could be framed as an optimization that would result in a single instance import like ("wasm-js:strings" "*") then being aliased off of, so that if/when we have compact imports, there would only be a single wasm-js string in the binary and that that would be something we could be ok with?

That is, can we make this decision in anticipation of compact imports that "wasm-js:strings" would work? Or would you also be concerned that there might be other factors here? And if so, what sorts of compact imports factors might alter how we'd think about this?

Would be good to discuss this further. Yes we can wait on this decision here, and still be able to decide later. But string constants are also an important piece of the string builtins story that we shouldn't delay on unnecessarily either.