Different compile-time import object designs

[eqrion]

The imports object for compiling has a different shape than instantiation. It's an array of key and value pairs, instead of the nested objects that instantiation uses.

There are several reasons for this:

1. Reading the instantiation imports object uses GetProperty which needs to know the import key
2. Compilation and decoding of imports section (which has the keys) may happen on a background thread that cannot read from the imports object
3. Compile-time imports are partially applied and need to distinguish between do not apply at compile-time and apply JS undefined. JS undefined is a valid import value and results from a get property of a missing property.

That being said, a big downside to the array of key/value pairs is that it's extremely verbose. The 'module' field is repeated every time.

One option that @rossberg proposed would be to use the same nested objects shape that instantiation uses, but limit the values to only those that are iterable on the object. This would simplify the API, but might lead to confusion as the import objects look identical but are not treated the same?

[Jamesernator]

Given that builtin modules like string will presumably have highly inter-related functions anyway, in most cases people will just want the whole module.

A simple sugar would be to simply allow omitting name to automatically import all members from the named module:

const mod = await WebAssembly.compile(bytes, {
    imports: [{
        module: 'string',
        value: WebAssembly.String,
    }],
});

[rossberg]

My primary reason for preferring using the same shape as the import object was exactly what @Jamesernator said: that one usually will want to pass the whole module. But some variation of his solution would work as well. Of course, it's still a seemingly arbitrary syntactic difference, but I don't care too much.

[eqrion]

As of #8 there are no more compile-time imports.