Andreas Rossberg

Interesting question. AFAICS, option 2 is the only viable one, for the reasons you mention. It makes instructions like ref.is_i31 and ref.as_i31 slightly more expensive in a JS embedding, but...

Yes, but nobody wants float semantics for their integers. ;) So that wouldn't replace a proper integer type or eliminate the issue you pointed out. Floatrefs may be useful in...

I see how this can be useful, though my gut reaction would be to consider this a post-MVP addition, since it is a local optimisation that doesn't add crucial functionality....

Right, but keep in mind that Wasm is an assembly language, so this is to be expected. Wasm code mostly mirrors what native code would have to do as well....

The JS API generally wants the ability to accurately express all types expressible within Wasm. This includes recursive types, but also other GC types. So (2) is needed. Type exports...

@askeksa-google, keep in mind that we don't have access to exports until we have instantiated a module. So you'd need a second module to instantiate and import the type from...

True, but of course, there might be reasons to construct/wrap the function explicitly. And this won't apply to use cases like putting functions in tables or passing function references.

We should either have a complete story for [bulk operators](https://github.com/WebAssembly/gc/blob/main/proposals/gc/Post-MVP.md#bulk-operations) on arrays, analogous to what we did for memories and tables, or defer. Let's avoid a one-off instruction. As mentioned...

If somebody else volunteers to do all the work (especially tests, interpreter, and spec text), then I certainly wouldn't stand in the way. But I do worry that it would...

> I take issue with "we should have a complete story, or nothing" arguments, they are fundamentally against the idea of an MVP. The concepts of MVP and incrementality don't...