Are we considering using Promises in the ImportObject?

[xtuc]

Following the discussion in webpack/webpack#6433 (comment).

@lukewagner mention the usage of Promises in the ImportObject for the instantiation.

While that works great for Globals, Memory, Tables and functions (functions aren't really impacted in fact). I think that's not going to fix the case were modules have cyclic dependencies.

Let A and B be two wasm modules; if A imports a func from B and B imports a func from A. A will be waiting for B's promise and B will be waiting for A's promise.

Maybe my example was previously misunderstandood but were's a response:

@lukewagner It would lead to an instantiation-time error when one wasm module's instantiation would read undefined from the binding, if that's what you mean.

Also that prevents A from importing itself.

---

Another point is that it strictly ensure the initialization order, which prevents Webpack to download and instantiate modules concurrently.

[lukewagner]

Great question!

There may be fundamental semantic reasons why we don't want to allow direct wasm-wasm cycles. @rossberg feels more strongly on the issue and can go into more details, but at the very least it would fundamentally change some aspects of core wasm semantics.

This is limitation could perhaps be relaxed in the future with sufficient use cases / motivation, but, until then, if the native ESM-integration spec disallowed cycles involving wasm, then bundlers that implemented the spec wouldn't have to worry about wasm-wasm cycles and thus could always find a DAG ordering to wire up promises via instantiate + Promise-imports.

To be clear, only (transitive) wasm<-->wasm cycles would be disallowed, wasm modules could still participate cycles involving ESMs as long as a given wasm module's imports from other wasm modules was properly ordered according to the postorder instantiation traversal.

[linclark]

I don't think anything else needs to happen in this issue, but we can reopen if that is not the case.