Anyref vs. Externref in JS-API

[eqrion]

On the web, externref can hold any JS value and funcref can hold exported wasm functions. In this proposal, anyref is added as the super type of externref and funcref.

Is there any difference between anyref and externref when used in a param of an exported wasm called by JS? Or generally in ToWebAssemblyValue [1]. It seems like if externref can accept any JS value, then anyref must as well as the super type of externref.

One oddity of this is that funcref and externref have overlapping sets of values. externref is any JS value and funcref is any exported wasm function (which is a JS value). So the subtypes of anyref aren't disjoint over the values they accept.

I haven't been able to write any code that would break with either of these facts, but I just want to make sure this is intentional and how I should read the proposal.

[1] https://webassembly.github.io/reference-types/js-api/index.html#towebassemblyvalue

[rossberg]

One oddity of this is that funcref and externref have overlapping sets of values. externref is any JS value and funcref is any exported wasm function (which is a JS value). So the subtypes of anyref aren't disjoint over the values they accept.

Yes, but that is neither a problem nor unusual. The same is the case for many types -- subtype hierarchies form lattices, i.e. DAGs, they aren't limited to trees.

For example, if we add the usual rules for function subtyping, and you have some types A <: B, then the function type [B]->[A] is a subtype of both [A]->[A] and [B]->[B], and both in turn are subtypes of [A]->[B].

AFAICS it's unavoidable (and desirable) that JS functions (at least the instances of the upcoming WA.Function) inhabit, or at least convertible to, both externref and funcref.

[RossTate]

@rossberg That's not really addressing the crux of the issue.

@eqrion In this proposal, if you upcast an externref value to an anyref, there is no reliable way within WebAssembly to downcast that anyref value back to an externref. It's a one-way street. The question is, is that one-way street useful?

[rossberg]

@RossTate, that seems to be a different question, with no specific relation to funcref? And re that question, why shouldn't it be possible to support a cast from anyref to externref?

[RossTate]

that seems to be a different question, with no specific relation to funcref?

The relation to funcref is that if you have a funcref value with an externref static type, then when you upcast the externref to an anyref you won't be able to downcast it back to an externref. The crux of the problem is that nearly all anyref values will also be externref values, and the overarching question is how are the two types any different then. funcref was just a concrete example given to illustrated the problem.

why shouldn't it be possible to support a cast from anyref to externref?

Given an arbitrary externref, you have no idea what rtts it has, so you cannot cast it within WebAssembly.

[rossberg]

The inhabitants of externref are up to a host embedding to define. It may or may not choose to overlap them with exported Wasm values. For example, with the C API as currently defined, its extern ("foreign") values are disjoint from any Wasm reference. For the JS API, we could decide to (almost?) collapse them into a single type. Though there is no particular reason to make, say, exported Wasm GC objects subtypes of externref, even for JS.

To allow casting down to externref the semantics just would have to act "as if" every extern reference had an RTT for externref. Whether that's desirable/worthwhile/necessary or not is a design choice.

[RossTate]

Yes, I forgot to make clear that my comment (and this entire issue) was in the context of the JS API.

To allow casting down to externref the semantics just would have to act "as if" every extern reference had an RTT for externref. Whether that's desirable/worthwhile/necessary or not is a design choice.

Okay, so you do agree with the statement I made above then? "In this proposal, if you upcast an externref value to an anyref, there is no reliable way within WebAssembly to downcast that anyref value back to an externref."

[tlively]

extern and any were unified in #271, making this issue moot.