Programmatic import resolution about wasm-c-api HOT 4 CLOSED

The current design is intentional. I think it is crucial to avoid making the basic interface higher-order, since that would be very inconvenient to map to plain C and even harder (and likely more costly) to access from FFI bindings.

The interface you propose can be implemented very easily on top of what's currently provided, but not vice versa.

(Also, there are valid use cases where it is simpler to treat imports/exports positionally and not having to care about their names at all, see e.g. the examples. Basically, whenever you are in control of the binary.)

from wasm-c-api.

The problem is that positional correspondence does not provide the embedder enough information to resolve imports at all, except by convention or out-of-band information such as parsing the imports itself. Names, kinds, and signatures are the language of imports, so a complete API needs to expose them.

(And about layering, you actually cannot implement named import resolution on top of positional correspondence without out-of-band information, whereas the opposite is easy if the contract is to request imports through the programmatic interface in import order).

from wasm-c-api.

Actually, sorry. Now that I look at it, I guess it is possible to extract the imports from the module itself and then do the lookups programmaticallly.

from wasm-c-api.

Yes, that was the idea.

from wasm-c-api.