@tlively and I briefly discussed this over coffee the other day. What if we layered this proposal on top of module-types (with linking as described in WebAssembly/module-linking#3), and used nested modules here instead of conditional sections?
At a first glance, there are some nice properties here. We can fix the unstable index problem (issues #21 and #10), because the outer module will always have a fixed module type. Any helper functions/types/etc. would be local to the nested module, and the outer module could then conditionally export whichever version it prefers.
It addresses module merging issues (issue #14), since again, the outer module can choose which inner components to export/define, and can be bound by whichever constraints we like (single memory, single start section, etc.)
There are no concerns about the name section (issue #16), since the names will be attached to the whichever module defines the function/global/etc.
I'm still not quite sure how the conditional nested imports will work, though. My initial thought is that this would be a switch, where a particular import comes from 1 of N modules choosing the first predicate that is satisfied. If the predicate is never satisfied, then the module is invalid. Similarly, module definitions would be conditioned on a single predicate.
Thoughts?
@tlively and I briefly discussed this over coffee the other day. What if we layered this proposal on top of module-types (with linking as described in WebAssembly/module-linking#3), and used nested modules here instead of conditional sections?
At a first glance, there are some nice properties here. We can fix the unstable index problem (issues #21 and #10), because the outer module will always have a fixed module type. Any helper functions/types/etc. would be local to the nested module, and the outer module could then conditionally export whichever version it prefers.
It addresses module merging issues (issue #14), since again, the outer module can choose which inner components to export/define, and can be bound by whichever constraints we like (single memory, single start section, etc.)
There are no concerns about the name section (issue #16), since the names will be attached to the whichever module defines the function/global/etc.
I'm still not quite sure how the conditional nested imports will work, though. My initial thought is that this would be a switch, where a particular import comes from 1 of N modules choosing the first predicate that is satisfied. If the predicate is never satisfied, then the module is invalid. Similarly, module definitions would be conditioned on a single predicate.
Thoughts?