Optional imports

[sbc100]

In WASI we are discussing adding optional imports (also known as weak imports in the ELF spec) on top of the existing import system: https://github.com/WebAssembly/WASI/issues/36.

For a more integrated solution I was thinking about a possible spec proposal to add the concept of a weak import. @binji and I discussed how this might work, at least for Function and Global imports:

1. New import types for weak_global and weak_function (or some bit to indicate the weakness of an import). These would exist in the same index space that strongly imported functions and globals.
2. A call to an undefined weak function would result in a trap.
3. A global.get or global.set on an undefined weak global would result in a trap.
4. New instructions func.check and global.check (taking function and global immediates respectively) could be used to check for the presence of the weak import at runtime.

One downside of this approach is that it is specific to functions and globals and doesn't necessarily to all possible types of imports.

[awtcode]

@sbc100 , does this mean that we can get rid of the JS import thunks like the following? function _sidey(){ Module["_sidey"].apply(null,arguments) }

[sbc100]

@sbc100 , does this mean that we can get rid of the JS import thunks like the following? function _sidey(){ Module["_sidey"].apply(null,arguments) }

Its not clear to me exactly what the purpose of that wrapper in particular is.

But in general with dynamic linking in emscripten we are going to continue to need to have JS thunks for at least some functions to work around the problem of circular dependencies. i.e. if two modules mutually depend on each other there is no way to simultaneously initialize them without providing some kind of thunk functions for thier mutual dependencies that then act and thunks into the real WebAssembly functions which become available only after instantiation.

In short, I think the problem of mutual imports is independent of that of weak imports.

[awtcode]

Thanks for your reply @sbc100 . Just to clarify, these wrappers are generated by Emscripten and not by me. They are used as import functions into the main module thru asmLibraryArg.

Perhaps, I don't understand about the use of weak imports in this context. Are weak imports a mechanism that we use to instantiate a Wasm module while the required import function is not defined?

[sbc100]

Yes, a weak import is one that can be undefined, but not just at initialization time, also at runtime. A weak import remains undefifined for the duration of the execution of the program.

Not to be confused with lazy loading or on-demand loading of symbols, which is a separate issue related to dynamic linking.

[guybedford]

This got me thinking if such a feature might be similarly useful on the JS side for a import { weak x as y } from 'module' which would allow a shared foundation in the ESM integration. Sample spec text at https://github.com/guybedford/proposal-weak-imports.

[erights]

At the WASI meeting on 15 August 2019, we decided to rename "weak imports" to "optional imports".