Compatibility with JS Structs proposal

[takikawa]

One design issue is that it would be good to aim for compatibility with the JS Structs proposal that is at stage 1 in TC39. It proposes a new "struct" construct for JS that is initialized all at once, and is non-extensible with additional fields (sealed). In the future, it may also have some notion of types (like typed arrays), though likely not in the initial proposal.

The reason for having compatibility is to avoid having two kinds of objects specified in JS that would have very similar features. While the Wasm JS API spec could specify its own kinds of exotic objects to represent customized Wasm GC structs, it would be better if the spec language could effectively say "it's a JS struct" with some additional constraints.

In addition, a main motivation for JS structs is to allow for shared structs that can be shared between threads. In the long-run, when Wasm GC interoperates with the threading proposal, we might have shared GC structs in the language. It would be desirable for these to be reflected as JS shared structs so that they could be shared between JS workers and work with the usual Atomics constructs.