Integration with import assertions

[littledan]

Now that import assertions are Stage 3, we have to decide how they will integrate with Wasm/ESM integration. There are two aspects of this:

• When importing a Wasm module from JS, does it need an explicit assert { type: "wasm" } or is this OK to be implicit (given that, currently, JS and Wasm run at the same privilege level Should WebAssembly be at the same "privilege level" as JS? #41)?
• WebAssembly modules will need a custom section which somehow note the import assertions. We'll want to design this custom section format to be future-proof to possible expansions of the import assertion grammar, and the possible creation of "evaluator" attributes. (previous mention)

[devsnek]

does it need an explicit assert { type: "wasm" }

I think need should be no, but an implementation should feel free to add that.

[littledan]

I guess there are two questions:

• How the integration should work in HTML
• How the integration should work in other environments

In HTML, implementations don't really have the freedom to add things--HTML is governed by a standard. We could make this mandatory, optional, or always missing, when used in HTML. But we won't let each individual browser choose its semantics.

Other environments can sort of do whatever they want--they don't have to align with HTML, or they can align but also permit looser behavior.

[annevk]

Do we envision the capabilities of Wasm and JS to diverge? If so, requiring an assertion might be prudent.

[Ms2ger]

When importing a Wasm module from JS, I don't think there's any reason to allow an import assertion, since the Wasm module can import other JS anyway. It remains possible to forbid that by using WebAssembly.instantiate() directly.

If we'd ever want to add a feature where JS imports Wasm that can't then import JS (though I don't see why we'd want to do that), we could use an import assertion for that - and it would be unfortunate if the obvious string was already taken here.

Import assertions for wasm importing json (for example) are an orthogonal issue, which I believe needs some work still.