JS-API is missing value conversions

[eqrion]

This is highly related to: WebAssembly/gc#279, but as this is a separate proposal I think it needs an issue here too.

1. What is the behavior of ToWebAssemblyValue for (ref null? T) when T = func-type. The explainer says for 'value conversions' that a type equality check is performed. The JS-API is missing this case. To be consistent with the current direction of WebAssembly/gc#279, it seems like we should disallow this case and throw an exception.
2. What is the behavior of ToWebAssemblyValue for non-nullable references when value = JS null? We currently throw a TypeError in SpiderMonkey, and this is similar to how V128 is handled.
3. What is the behavior of ToWebAssemblyValue for (ref extern) when value = JS null. The same as above? I call this one out just to clarify my mental model that heap-type extern can hold every JS value except for JS null, which becomes a null reference value in WebAssembly and therefore requires the reference to be nullable.

https://webassembly.github.io/function-references/js-api/index.html#towebassemblyvalue

[jakobkummerow]

My suggestion is to disallow non-nullable reference types in JS interop. But apparently some folks think that we should support everything everywhere... in which case we'll have to answer these questions (and perform the corresponding checks at runtime, if modules actually use these types).

Point 3, non-nullable (ref extern), makes particularly little sense to me. "This can hold any external reference value as an opaque reference that Wasm doesn't care to inspect, except null" (which, I agree, is what (ref extern) means) just isn't a concept I find convincing.

[rossberg]

1. What is the behavior of ToWebAssemblyValue for (ref null? T) when T = func-type. The explainer says for 'value conversions' that a type equality check is performed. The JS-API is missing this case. To be consistent with the current direction of JS interop: no-frills approach gc#279, it seems like we should disallow this case and throw an exception.

Makes sense to me. I'm happy to adjust the doc once we have agreement on what we want to support.

Personally, I'd be fine with only supporting anyref, externref, and funcref.

2. What is the behavior of ToWebAssemblyValue for non-nullable references when value = JS null? We currently throw a TypeError in SpiderMonkey, and this is similar to how V128 is handled.

The doc says that "the null value is allowed as ref null ht", which is meant to imply that it is not allowed for anything else, i.e., should trap.

3. What is the behavior of ToWebAssemblyValue for (ref extern) when value = JS null. The same as above? I call this one out just to clarify my mental model that heap-type extern can hold every JS value except for JS null, which becomes a null reference value in WebAssembly and therefore requires the reference to be nullable.

Yes. FWIW, I agree that (ref extern) isn't a particularly useful type, but we don't want to introduce special rules for it.

@jakobkummerow:

My suggestion is to disallow non-nullable reference types in JS interop.

If we support concrete types (ref null $t), then we should also support (ref $t), which I assume is actually cheaper. But for the MVP, I'd rather suggest we include neither.

[rossberg]

I updated the Overview to reflect the no-frills decision. So I think we can close this issue.