Motivation for externref <: anyref

[RossTate]

#130 and #142 identify some disadvantages to having externref be a subtype of anyref. I am wondering what the advantages are. Note that, after upcasting externrefs to anyrefs, there is no reliable way to downcast the resulting anyrefs back to externrefs, making the subtyping a one-way street. Consequently, it seems to me that a module mixing externrefs with its own values (uniformly represented as anyrefs) would want to box the externrefs in some manner, both to provide a way to later unbox them and to prevent bugs that could be caused by unintended/unanticipated overlaps between externref values and the module's own values. This boxing pattern would not need externref to be a subtyping of anyref. And if the boxing pattern is indeed common and we leave externref as a subtype of anyref, then that would mean that foreign references would first get boxed to become externrefs that are compatible with anyrefs, which would then get boxed again by the application, and then the reverse for unboxing.

[rossberg]

If extern references weren't interchangeable with GC references, then we'd be violating a basic design goal of Wasm, namely that imports can equally be implemented by another Wasm module or primitively by the host, and that imported modules can be both host-implemented or self-hosted, and the difference is transparent. Frameworks like WASI make use of this ability, which is just a basic abstraction principle.

[jakobkummerow]

I suppose an example would be a module that's built to run in a browser context, and tracks (opaque imported extern) references to HTMLElement and various subtypes thereof; and then you might want to run that module in a headless (server?) environment where DOM interaction is stubbed out by a "fake DOM" module, which would have to be able to provide its own structs/arrays as "fake externrefs".

It took me a while to see this reasoning, but the example above I find reasonably convincing as something we'd want to support.

(I suppose the question one could ask is: how important is it to have support for subtyping hierarchies among imported opaque types? For a human-written language, one would absolutely want that; for a compiler-generated wire format like Wasm, I'm not so sure: X-to-Wasm compilers could track such types internally in order to detect typing errors early; emitting them into the Wasm module doesn't seem essential for that functionality.)

[RossTate]

If extern references weren't interchangeable with GC references, then we'd be violating a basic design goal of Wasm, namely that imports can equally be implemented by another Wasm module or primitively by the host, and that imported modules can be both host-implemented or self-hosted, and the difference is transparent.

@rossberg This statement seems to be predicated on the assumption that all imported types need to be a subtype of anyref to be useful. Is that true? I am asking why that subtyping helps with externref.

@jakobkummerow This seems to be an argument for why we would want to support subtyping between imported types, which is something I agree with. But I do not see how this argues for the specific subtyping externref <: anyref.

[tlively]

we'd be violating a basic design goal of Wasm, namely that imports can equally be implemented by another Wasm module or primitively by the host... Frameworks like WASI make use of this ability, which is just a basic abstraction principle.

Actually, this goal is already violated by all existing proposals as far as WASI is concerned because they need to be able to implement their imported capabilities in terms of number types, not GC types. Fixing that is a separate discussion, but I do want to push back on the assertion that WASI depends on externref <: anyref.

Edit: Responding to @tschneidereit's later question inline up here to avoid derailing discussion further.

the intent for WASI is to use reference types instead of numbers to represent capabilities

Yes, the intent for the interface presented to client modules is that capabilities are reference types (or more specifically, opaque type imports), but for the virtualization use case, it would be much better if the virtualizing modules implementing that interface could use normal types (i.e. i32) that could be manipulated natively in their source language. If both sides of the interface were required to use reference types to represent capabilities, it would be impossible to implement a WASI interface in Rust, C, or C++ (without extremely intrusive language extensions).

[jakobkummerow]

predicated on the assumption that all imported types need to be a subtype of anyref to be useful

I see an implication in the other direction: starting with viewing "externref" as an entirely opaque reference, where a module doesn't know or care what such a reference might be referring to, implies in particular that it might be a reference to another module's GC type.
At the very least, that causes engines to have to use the same representation internally (because when the first module is compiled, the engine can't know yet what imports it will be instantiated with).
As far as the type system is concerned: such a second module needs a way to cast its own GC types to the first module's externref. I suppose we could put special magic into the cross-module type interaction system to let it bridge an otherwise un-castable divide between distinct type hierarchies. But then arguably it is cleaner and simpler to just say that there is no such divide.

[RossTate]

@jakobkummerow I'm not entirely sure I understand your argument, so apologies if this response is misdirected. That said, here are a few thoughts.

1. externref does not need to be a subtype of anyref for it to be possible to instantiate an imported type with externref and with a wasm reference type without recompilation. From a GC perspective, what matters is that they are consistent with which bits represent integers versus addresses (which they currently are in V8) and with how the GC description is represented (which they currently are in V8). So, without the subtyping, it's perfectly possible to use Smis for externref and i31ref for anyref and yet use either representation for an imported type.

2. This requirement that we be able to instantiate an imported type differently without requiring recompilation has not been particularly motivated. For practical purposes, all that seems to be useful is for multiple instantiations with closely related types to be able to reuse the same compiled binary. Closely related does not necessarily mean subtypes; it could be something abstract like "reference types".

3. To @tlively's point, it could be more useful for externref or imported types to be able to represent non-reference types.

From an application's perspective, I suspect applications will fall into one of two camps: the application is willing to rely on or trust that the imported type follows some convention, or it is not. In the latter case, even if an imported type (or externref) is a subtype of anyref, the application will box and unbox externref values manually in order to keep foreign values distinct from their own. In the former case, the application's needs are likely met by importing coercions between the imported type and the type representing the convention (whether it is anyref or some more specific type). The imported coercion from the imported type to the convention type could just be an upcast (i.e. a no-op), and the reverse direction could just be a down cast (i.e. an rtt cast). Either way, subtyping does not seem particularly necessary/helpful. Actually, there's a third camp: the application makes no use of the GC proposal, e.g. all current applications. Pragmatically speaking, though, this camp is akin to the boxing/unboxing camp.

[tschneidereit]

Actually, this goal is already violated by all existing proposals as far as WASI is concerned because they need to be able to implement their imported capabilities in terms of number types, not GC types.

Can you expand on this a bit? I'm probably missing something, since the intent for WASI is to use reference types instead of numbers to represent capabilities. Wherever numbers are needed I'd expect WASI to stick to Wasm core types.

[RossTate]

In order to avoid going into the specifics of WASI, I think the meta-point is that a good compositional/modular design would not require us to consider WASI's implementation strategy nor would impose constraints on WASI's implementation strategy. Removing the externref <: anyref (or $import-type <: anyref) subtyping removes the dependency, which is why it would be nice to have a solid motivation for having that subtyping.

[rossberg]

@tlively, I am a bit astounded but what you're saying. The WASI (and WASI-like) use case was the main motivation for the CG to ask to split type imports from the GC proposal. So it is highly relevant to this question. And the ability to transparently virtualise/poly-fill/self-host system modules (and vice versa) has always been a goal for Wasm and came up regularly in CG discussions. How do you suggest reconciling this goal without making extern refs and Wasm refs interchangeable?

[RossTate]

@rossberg The OP is very clearly questioning (with arguments) whether the subtyping in question is practically useful for this interchangeability. It is frustrating to have you equate removing the subtyping in question with removing interchangeability without addressing, let alone acknowledging, the points in the OP. A much more helpful way to advance the conversation would be to give a concrete example illustrating why you believe these to be effectively the same. If they're obviously effectively the same, then providing such an example should be easy. Ideally this example should not just as easily work with importing coercions, since coercions do not have the downsides of #130 and #142.

[rossberg]

The need for interchangeable representations does not generally imply a need for downcasts, especially in the type import scenario, which is essentially parametric polymorphism. So my observation here is that we gain nothing by assuming a distinction in the subtype relation -- the representations already have to be compatible anyway, and casting is a separate concern.

Even when using subtyping and downcasts, the side for which the ability to downcast primarily matters is the one producing the values. And that side always has a choice to make that possible. If it is Wasm code, it can create values with appropriate RTTs. If it is the host, then it has full freedom to use extra-linguistic means and enrich its own object representation to allow recognising their types.

Furthermore, a host environment also has the choice of enabling custom object layouts which the Wasm-side can view as RTT-carrying. In general, it can be useful to enable Wasm to downcast host objects to concrete import types, by importing a respective host RTT. OTOH, it is hardly useful to downcast to an abstract type like externref itself. (FWIW, in discussions with @jakobkummerow and @tebbi we recently concluded that the RTT mechanism and the actual cast instruction only needs to work for concrete data types, and I am working on a change to simplify the proposal that way. More on this later.)

[RossTate]

It sounds like you're saying you have no application for externref <: anyref. Rather, your argument for the subtyping is "the representations already have to be compatible anyway". This argument was already addressed above (point 1 specifically), and the OP discussed the costs imposed by having an unnecessary subtyping (e.g. double boxing).

[tlively]

@tlively, I am a bit astounded but what you're saying. The WASI (and WASI-like) use case was the main motivation for the CG to ask to split type imports from the GC proposal.

AFAICT, WASI needs non-reference type imports to realize their goal of virtualizing interfaces that deal in abstract types from C/C++/Rust, since it is unlikely that Rust will ever have first-class support for reference-typed values. I thought I had raised this issue before, but I guess not because now I can't find any discussion about it.

At any rate, I think the answer to the original question here is clear: given the currently proposed type-import mechanism, externref <: anyref is necessary to make externrefs and GC refs interchangeable. Any dissatisfaction with the premise of that answer should be taken up in separate issues on the type-imports repo.

[titzer]

@RossTate

Note that, after upcasting externrefs to anyrefs, there is no reliable way to downcast the resulting anyrefs back to externrefs, making the subtyping a one-way street.

This isn't really different than any other subtyping relationship currently proposed for references: upcasts are free (subsumption, no representation change) and downcasts require an RTT witness value that has an RTT type which literally encodes a nominal subtyping chain. The GC proposal doesn't have RTT types for externref, but I don't understand why it couldn't have one, whose witness value could be gotten with rtt.canon externref. Failing that, one can always import a downcast operation (i.e. a function import) from the host environment.