Should we reverse the `externref <: anyref` relation?

[jakobkummerow]

Maybe this is a bad idea... it just occurred to me while thinking about issue #254, so I thought I'd write it down.

The current design is (skipping the ...ref parts of names for brevity):

        any
      /  |   \
extern   eq   func
        /  \
     i31   data

Which causes at least the following difficulties:

• Given an externref, one can (implicitly) upcast to anyref, and check ref.{is_func,is_data,is_i31} and even downcast accordingly, which violates the notion that externrefs are opaque.
• By using externref on its interface (e.g. to consume function arguments), a module can demand to be passed objects that can't be constructed by another module, as there is no Wasm way to construct externref values (they can only come from the host). While we could argue that it is each module's responsibility not to be silly, people have also argued that it's a key requirement that a module's functions that assumed to be called with host-provided externref values can also be called from another module with fake/polyfilled/wrapped/layered, i.e. module-constructed values.

I think one way to address these difficulties could be to swap the subtyping relationship, and make the intended-to-be-opaque type the top type:

 extern (maybe better named "opaqueref" then?)
   |
  any  (maybe better named... uh... "bikeshedref" then?)
  / \
eq  func
| \
...

Notably, ref.is_* and ref.cast would continue to consume anyref values, which addresses the first difficulty mentioned above. Semantics of externref is "I don't know or care what this is, and that implies I won't try to inspect it" (i.e. closer to void* in C than to Object in Java, though of course both of those comparisons are rather imperfect because Wasm is neither C nor Java).

The second difficulty mentioned above is addressed rather trivially by continuing to allow implicit upcasts to supertypes. That means to call a function that consumes an externref, the caller can pass any anyref it happens to have handy, or a struct/array it created, etc.

This wouldn't make fat pointers or other non-unified representations any more feasible than they were before, but as discussed elsewhere any dreams of doing that are very unlikely to become reality in engines anyway, even if the type system allowed it.

(Side note: whether funcref should really be non-eq is a question that might deserve separate discussion. I'm totally on board with not wanting JavaScript-style distinguishable-object semantics for distinct references to the same function. But the opposite, i.e. requiring canonicalization, aka requiring that (ref.eq (ref.func $f0) (ref.func $f0)) always returns true/1, could provide interesting expressiveness (specifically, I'm thinking of toolchain-side optimizations such as building caching/fast-path schemes in userspace), and shouldn't break any scenario that was possible when funcrefs were not ref.eq-comparable. But let's open a new issue if anyone wants to discuss that. It's related here because if we did make that change, then eqref could take the place of anyref, and then we'd at least have a name for the thing.)

Feel free to tell me why that can't work, and close this issue :-)

[skuzmich]

It will be useful to be able to test and cast externref to GC struct references when we will be able to view GC structs as JS objects with methods and properties.

For example, in Kotlin, we can have external interface that can be implemented either as JS object or an instance of Kotlin class. We could down cast it by round-tripping it through JS and getting it back as dataref. But would there be a way to test it, or do br_on_ things?

[jakobkummerow]

@skuzmich : you would use anyref (or whatever it'd get renamed to) as the type then. externref ("opaqueref") would be strictly for cases where you only want to pass around opaque references. (My understanding that that's the intention of externref even today, except the current GC proposal doesn't enforce that you can't do more with them, which seems like a bit of a bug to me.)

[skuzmich]

I must have wrongly assumed that only externref would be able to represent plain JS values. If anyref can store any JS value, looks good to me.

[rossberg]

I'm not opposed to introducing a common supertype for all Wasm references, if that's what you're looking for. But that is a separate design question from anyref. In that regard, your proposal essentially equates/repurposes the existing anyref with/as externref, which has the potential disadvantages I already mentioned.

[jakobkummerow]

I'm not opposed to introducing a common supertype for all Wasm references, if that's what you're looking for. But that is a separate design question from anyref.

I don't follow. In the current proposal, anyref is the common supertype for all Wasm references. So no, I'm not looking to introduce a common supertype; and I also don't see how "common supertype" and "anyref" are separate design questions.

the potential disadvantages I already mentioned.

You probably mean this:

Requiring that every Wasm reference can be externalised in every possible host environment would be quite a significant requirement, so assuming anyref = externref as opposed to just anyref >= externref is probably not a good idea in general, even if it could work in JS engines specifically.

which I'm also not following. By making externref a subtype of anyref, the two are required to have identical representation+interpretation anyway; in particular situations such as "one of them is garbage-collected and the other isn't" or "one of them is pointer-tagged/NaN-boxed/whatever and the other isn't" are ruled out.
And I have frankly no idea what you mean by "requiring that every Wasm reference can be externalised". What does it mean to "externalise a reference"?

The other part of that post you linked:

[anyref] is the only type that can abstract from whether some abstract reference (or type) external to a module is implemented in Wasm or by the host. Since making such abstraction possible is a stated goal of Wasm, anyref is needed.

is precisely what motivated the idea presented here. Currently, when a module says "I want an externref here", then it makes it impossible for its embedding environment to choose whether that value is implemented in Wasm or by the host. As far as I understand it, the current design does not meet the requirement that you characterize as "stated goal of Wasm". (It does as long as modules collectively choose not to use externref at all; but if that's what we expect to happen, why should we have externref in the first place?)

[rossberg]

I'm not opposed to introducing a common supertype for all Wasm references, if that's what you're looking for. But that is a separate design question from anyref.

I don't follow. In the current proposal, anyref is the common supertype for all Wasm references.

No, in the proposal it deliberately is the top type of all references, Wasm or external. OTOH, a type that is a common supertype of only Wasm types like i31, data, and func does not currently exist.

And I understand the appeal of introducing such a type: it would allow us to restrict type tests to proper Wasm values, excluding externrefs from such tests. In particular, that would solve the i31 issue you mentioned.

OTOH, @skuzmich just pointed out that they make use of that testability. Hard to say if that is strictly necessary with more context.

Requiring that every Wasm reference can be externalised in every possible host environment would be quite a significant requirement, so assuming anyref = externref as opposed to just anyref >= externref is probably not a good idea in general, even if it could work in JS engines specifically.

which I'm also not following. By making externref a subtype of anyref, the two are required to have identical representation+interpretation anyway; in particular situations such as "one of them is garbage-collected and the other isn't" or "one of them is pointer-tagged/NaN-boxed/whatever and the other isn't" are ruled out. And I have frankly no idea what you mean by "requiring that every Wasm reference can be externalised". What does it mean to "externalise a reference"?

That you can pass it to the host, either as argument/result or by export. It might well be conceivable that we could have Wasm references in the future that we do not allow to be passed to e.g. JS (for example, because it would be too expensive to maintain their type safety in JS), so JS could never produce them as externref either.

[anyref] is the only type that can abstract from whether some abstract reference (or type) external to a module is implemented in Wasm or by the host. Since making such abstraction possible is a stated goal of Wasm, anyref is needed.

is precisely what motivated the idea presented here. Currently, when a module says "I want an externref here", then it makes it impossible for its embedding environment to choose whether that value is implemented in Wasm or by the host. As far as I understand it, the current design does not meet the requirement that you characterize as "stated goal of Wasm". (It does as long as modules collectively choose not to use externref at all; but if that's what we expect to happen, why should we have externref in the first place?)

Yes, in the future, you should never be using externref in module signatures if you want to abstract over a type's origin. You should always be using anyref. That's its main purpose.

It is correct that that is currently impossible, because we removed anyref. I certainly won't argue that this was a move that made forward compatibility easier. ;) Externref was a stopgap. Once we have anyref back, it essentially replaces it for almost all practical purposes.

(I remember having given a similar reply to somebody else years ago, but I can't find it anymore.)

[jakobkummerow]

in the proposal [anyref] deliberately is the top type of all references, Wasm or external. OTOH, a type that is a common supertype of only Wasm types like i31, data, and func does not currently exist.

OK, thanks for clarifying that distinction.

["externalising a reference" means] That you can pass it to the host, either as argument/result or by export. It might well be conceivable that we could have Wasm references in the future that we do not allow to be passed to e.g. JS

I categorically reject the notion that hypotheticals should be considered hard design constraints. If something, no matter what it is, will only potentially hypothetically become useful eventually, then it should be designed if and when that happens, not now.

That said, this argument/idea doesn't make sense to me, for the following reasons:

• I can see that by using externref as the type of some provided function's argument, the host can restrict that one function to "only call this with one of the values I gave you, not with something you constructed yourself". But as long as we allow anyref on the interface (and that is anyref's purpose!), the existence of a distinct externref <: anyref does not help us establish a general-purpose barrier to prevent a certain class of values from being passed to the host in general or to JS in particular
• when passing a value as argument/result or export, a module doesn't (and shouldn't) know whether that means passing it to the host or to another module
• if we want to limit JS interaction for certain values, then specifying TypeErrors in the JS-API spec (like we already do, e.g. for s128) is the way to do that, not the core Wasm type system
• externref is primarily for values that already exist on the host side (e.g. in JS) and are being passed into Wasm (opaquely), not the other way round. Wasm can't construct any externref values anyway. It can only import/receive them.

Yes, in the future, you should never be using externref in module signatures if you want to abstract over a type's origin. You should always be using anyref.

That does beg the question: what do we need externref for, once we have anyref?

Using it anywhere other than a module's signature doesn't make sense anyway; externref values can only come from the module's signature. And abstracting over types' origins is, for good reasons, generally considered desirable.

I can see a use case for an "opaque reference" type, but I continue to think that that's better expressed as a supertype of inspectable reference types than as a subtype. (Because subtypes are where capabilities are added: roughly, the current Anyref would be the subclass of Opaqueref that adds is_data/is_i31 methods etc., just like Eqref is the further subclass that adds an is_ref_equal_to method.)

I can also see mental models as a "use case": as humans, we think "the set of all references consists of Wasm-created references and external references", and while that's undeniably true, that doesn't imply that the type system to reflect this must necessarily be structured as anyref = externref | wasmref: we can collapse externref into anyref if the two serve the same use case in practice, and one of them does it better than the other.

Looking at the earlier discussion and decision, the key point was the decision that (the old) anyref shouldn't be a supertype of funcref. At the time, that left only external references as its use case, so it was renamed externref to reflect that. One could say that what we really meant by that name was anything-except-func-ref. I don't think we decided that structs/arrays/i31 shouldn't be subtypes of that.

(It is also at least somewhat doubtful whether the GC proposal really constitutes a use case for funcref <: anyref. I don't recall anyone presenting a compelling argument why any reasons that used to hold for separating the type hierarchies are no longer holding. That said, whether and how funcref is put (back) into the anyref hierarchy is a separate design question from whether we should have externref <: anyref, anyref <: externref (or renamed: inspectableref <: opaqueref), or anyref == externref.)

[jakobkummerow]

@skuzmich : Thinking about your use case more, there are two aspects to it:

(1) Viewing Wasm GC structs as JS objects: that direction doesn't depend on the specifics of the Wasm type system. At some point we'll have a Wasm-JS API spec indicating what types to use on function signatures to make that work (could be externref/anyref/dataref/eqref, doesn't really matter).

(2) Passing values into Wasm which can be implemented either by another Wasm module or as JS objects, and then finding out on the Wasm side which case it is: that wouldn't be supported directly by the design sketched above. That's pretty much intentional though, as it's the flip side of fixing the leakage of host implementation details in the current externref design, which an opaqueref would properly encapsulate. You could work around it with a custom wrapper that has two fields and a way to indicate which of them is populated (roughly: (struct $wasm-or-external (field $wasm (ref $kotlin.Any)) (field $external externref) (field $which-is-it i32))).

If I understand (2) correctly, you're basically building an abstraction layer that accepts both JS and Wasm objects, and for e.g. loading a field uses either struct.get (directly, or via calling some Wasm function) or a call to a JS function that reads the corresponding property off the JS object? That's an interesting use case that I didn't have on my radar. I'd be curious to learn more about the goals, the approach, and the costs (performance and code complexity). I think this might be a very interesting point to consider when we get to designing the WasmGC-JS interop.

@rossberg : Note that this is an example where the current design is being used to do the exact opposite of abstracting over where a value comes from. Maybe that's a use case we have to support, but then we should openly say that that's the reason for the current design, as opposed to claiming the opposite.

[skuzmich]

If I understand (2) correctly, you're basically building an abstraction layer that accepts both JS and Wasm objects, and for e.g. loading a field uses either struct.get (directly, or via calling some Wasm function) or a call to a JS function that reads the corresponding property off the JS object?

@jakobkummerow Not exactly. Hopefully this example would clarify the use-case:

// Represents any JS value with a "foo" method.
external interface EI {
   abstract fun foo(x: Int): Int
}

class C : /*implements*/ EI {

  // This override would add a "foo" JS method to instances of C class via WasmGC-JS interop
  override fun foo(x: Int): Int { 
      return x + 1;
  }

  // This is a regular Wasm-only method
  fun regularKotlinMethod() { /*...*/ }
}

fun bar(ei: EI) {  // EI represented as `anyref`

   // This always calls imported JS function `(_this, x) => _this.foo(x)`
   // regardless whether anyref refers to Wasm struct or pure JS object
   ei.foo(2); 
                  
   // Test that ei is implemented as instance of C class.
   // Currently, this would be `ref_is_data + ref_test + check_nominal_instance_of_C`
   if (ei is C) {

       // Cast ei to C type. 
       // c has wasm type `(ref struct $C)`
       // Currently this would be `ref_as_data + ref_cast`
       var c: C = ei as C;
 
       // This always call wasm function foo via vtable or direct call
       c.foo(3); 

       // We can use c as a regular instance of C
       c.regularKotlinMethod()
   }
}

fun main() {

   // getJsObject could be a JS function that returns object literal,
   // for example `() => ({ foo(x) { return x; } })`
   var jsObj: EI = getJsObject();

   // We can call `bar` with either JS object ...
   bar(jsObj);
   // ... or an instance of C which is also can also be viewed as "JS object with method 'foo'"
   bar(/*new*/ C());
}

[jakobkummerow]

@skuzmich Thanks! bar is what I called "an abstraction layer that accepts both JS and Wasm objects". While your example doesn't have it, you could have type-specific dispatch in there if you wanted:

if (ei is C) {
  var c: C = ei as C;
  c.foo(3);  // Wasm call
} else {
  ei.foo(2);  // JS call
}

Funky!

[RossTate]

Thoughtful perspective! I see the merit to the overall idea. At the same time, I'm going to add some nuance by approaching this from a usage-directed take.

Here are three broad categories of embedders I can see for Wasm:

1. Homogenous GC: The external system is garbage collected and represents its heap objects much like wasm does. The JS embedding belongs in this category.
2. Heterogenous GC: The external system is garbage collected but represents its heap objects differently than wasm; the GC can still collect cycles across the two, but must take care to mode switch at the appropriate points. This is the category an OCaml embedding could belong—the OCaml GC packs its object descriptor directly into the header by using integer tagging and very few kinds of objects, but one such descriptor could indicate that the object has a single field pointing to a wasm instance/reference and the GC needs to switch to using unpacked object descriptors. (I'm not saying this is a use case we definitely need to serve, but I'm using the hypothetical to help break down concepts.)
3. Wasm-Only GC: The external system is not garbage collected. The C embedding belongs in this category.

For each of these cases, we can ask: how much sense does it make to have a common supertype of foreign (reference) values and wasm references (without worrying about which one is a supertype of the other or if there's some "union" type):

1. Possibly. There are issues that arise though. One that's been discussed a bunch is that it can't really be a union because of smis vs i31refs, and so really one has to ceorce from the foreign values to this unioned representation.
2. No. The two are represented fundamentally different and the heterogeneous GC needs static info to keep them apart. The best you could do is have a wasm-like representation that boxes an ocaml reference, but that comes with semantics issues like what to do if that ocaml reference was a boxed wasm reference, and you could just as well represent this manually with struct externref anyways.
3. No. I mean, I guess you could do boxing, but do we really want to require memory allocation for using what typically would just denote void* in calls to C?

So subtyping relationships do not seem to be a great fit. But there's another option: coercions. This option is easiest to understand in the Heterogeneous GC embedder. OCaml values include boxed wasm values, and can wasm easily include boxed OCaml values (ref (struct externref)). So its the same data, just different ways to represent the data. Coercions could simply change between these representations. Since we're talking about the code you'd write in wasm, you can do the coercion from ref (struct externref) to externref yourself. For the other direction, there could be some instruction that takes an externref and branches to an appropriate label depending on the type of data that externref describes (e.g. a boxed wasm reference from my instance's nominal hierarchy, or a (boxed) integer or float, or some truly foreign externref that might even be a wasm reference from an unrelated instance).

Coercions could work well just as well for JS, and in many cases the coercion would do nothing (besides test if the value is already a wasm reference). There's even room for optimizing the coercions to and from smis.

But for a C embedder, these coercions do not make as much sense. And I think that's where the concerns about assuming too much of a relationship between foreign "references" and wasm references make sense (at the same time, I do not see how one can express those concerns and at the same time say that externref should be a subtype of anyref).

So how do we bridge this gap? The two options that came to mind are (a) inlinable imports for testing and coercing (b) embedder-specific instructions for testing and coercing. Both have their pros and cons, and I'm not gonna digress further on them here.

---

As for abstracting over externref via reference type imports, I do not think that's a pragmatic requirement. For one, it has roughly the same answers for "does it make to have a common supertype of foreign (reference) values and wasm references". For another, interfaces for GCed systems generally have key differences from interfaces for non-GCed systems, I mean, hypothetically one might be able to develop a practical system where a module could be implemented by either wasm references or arbitrary "foreign" references, but it seems like a big hypothetical right now, especially given that we're not even support separate compilation for the MVP and that there's a really simple fallback: use ref (struct externref) instead.

On the other hand, it does make sense to abstract externref via value type imports. But that's also definitely not something we need for the MVP.

Update: For homogenous GC embeddings, if we make it possible to import reference types that cannot be unioned with i31ref, then it would be easy to allow an abstract type import to be instantiated to represent foreign references (e.g. JS values).

---

So all that's to say that your idea makes sense for the JS embedder (and a hypothetical OCaml embedder), except that I'd replace subtyping with coercions that are either provided through inlined imports or through embedder-specific instructions.

[rossberg]

@jakobkummerow:

["externalising a reference" means] That you can pass it to the host, either as argument/result or by export. It might well be conceivable that we could have Wasm references in the future that we do not allow to be passed to e.g. JS

I categorically reject the notion that hypotheticals should be considered hard design constraints. If something, no matter what it is, will only potentially hypothetically become useful eventually, then it should be designed if and when that happens, not now.

I agree in general, though I would put quite a bit more nuance to it than rejecting it categorically. Yet in this case, I certainly wouldn't claim that it is a strong reason.

That said, this argument/idea doesn't make sense to me, for the following reasons:

• I can see that by using externref as the type of some provided function's argument, the host can restrict that one function to "only call this with one of the values I gave you, not with something you constructed yourself". But as long as we allow anyref on the interface (and that is anyref's purpose!), the existence of a distinct externref <: anyref does not help us establish a general-purpose barrier to prevent a certain class of values from being passed to the host in general or to JS in particular
• when passing a value as argument/result or export, a module doesn't (and shouldn't) know whether that means passing it to the host or to another module
• if we want to limit JS interaction for certain values, then specifying TypeErrors in the JS-API spec (like we already do, e.g. for s128) is the way to do that, not the core Wasm type system

Yes, what I imagined is that it would e.g. be a runtime type error (in the JS API) if you tried to externalise such a wasm-only reference. Thus it cannot exist on the JS side, and consequently, does not inhabit externref. Another alternative (probably not very useful) would be that it gets coerced to / wrapped in a (useless) opaque host reference that cannot be converted back to the original Wasm type (because, in this example, there wouldn't be a way to ensure type correctness). Under that alternative, you would get an externref, but it's different from the original wasm ref and not observable as such anymore.

• externref is primarily for values that already exist on the host side (e.g. in JS) and are being passed into Wasm (opaquely), not the other way round. Wasm can't construct any externref values anyway. It can only import/receive them.

Correct, but does not contradict what I said. To the contrary, my point was that there is reason to assume a dual counterpart as well: wasm-only refs that are mutually exclusive with externref. And then anyref is the only common supertype of both.

Yes, in the future, you should never be using externref in module signatures if you want to abstract over a type's origin. You should always be using anyref.

That does beg the question: what do we need externref for, once we have anyref?

Yes, as I said, as an explicit type in the language, we'll hardly do.

I can see a use case for an "opaque reference" type, but I continue to think that that's better expressed as a supertype of inspectable reference types than as a subtype. (Because subtypes are where capabilities are added: roughly, the current Anyref would be the subclass of Opaqueref that adds is_data/is_i31 methods etc., just like Eqref is the further subclass that adds an is_ref_equal_to method.)

Yes, and as mentioned, I don't disagree with you that such a type has merits. I'm merely pointing out that it is a different type from anyref, and consequently, that adding it is a different discussion. I simply don't want to conflate removing anyref with adding this other type. Technically, both exist and could be added, independently of one another.

I can also see mental models as a "use case": as humans, we think "the set of all references consists of Wasm-created references and external references", and while that's undeniably true, that doesn't imply that the type system to reflect this must necessarily be structured as anyref = externref | wasmref: we can collapse externref into anyref if the two serve the same use case in practice, and one of them does it better than the other.

Yes, in practical terms, we could collapse them. Though that would introduce two synonym type names, which is a bit ugly.

However, is there any particular advantage in doing so at this point? It's not like differentiating both these types adds much complexity.

So in summary, I wouldn't be opposed to simply renaming externref to anyref. But I don't think it has much benefit either. And I'm up for adding the third type you proposed, but would definitely call it something else. Does that make sense?

[rossberg]

@jakobkummerow:

@rossberg : Note that this is an example where the current design is being used to do the exact opposite of abstracting over where a value comes from. Maybe that's a use case we have to support, but then we should openly say that that's the reason for the current design, as opposed to claiming the opposite.

I think you are assuming a different meaning of abstraction than I am. Abstraction does not imply that you cannot find out anything about it. (E.g., a regular function is also abstracting over its concrete argument value, yet it can certainly inspect it and find out what it got.)

In the context of typing, there also is the particular notion of "parametric type abstraction", where you indeed cannot find out what the type is. Perhaps that's what you had in mind, but that is a particularly strong form of abstraction.

[askeksa-google]

Passing opaque references to Wasm, only to store them and eventually pass them out again, is an important use case. And it certainly appears useful to be able to do this for all references (Wasm or external), oblivious to their origin.

Consider the four scenarios proposed:

1. externref disconnected from the rest of the hierarchy (with or without anyref): Can't abstract over the origin of opaque values.
2. externref <: anyref: Can't abstract over the origin of opaque values, unless they are represented as anyref, making externref redundant.
3. externref merged into anyref: Can abstract over the origin of opaque values. Requires the engine to support all refs (not just Wasm refs) in tests/pre-casts (ref.{is,as}_{data,func,i31}). May entail some checks/conversions at the boundary, e.g. as described in i31ref conflicts with JavaScript-numbers encoded as tagged 31bit values #76.
4. anyref <: externref (with anyref only accepting Wasm refs): Can abstract over the origin of opaque values. Allows the engine to have tests/pre-casts only working on Wasm values. Could make passing externref values more efficient, since no checks will be needed (assuming a uniform representation).

With option (4), we can still add instructions to test/convert an externref to anyref. These would then perform the same checks/conversions as are needed when passing a value into anyref. The engine is free to have host values and Wasm values overlap (e.g. for i31).

Based on these observations, I think anyref <: externref can be a good avenue for supporting all the various use cases in a "pay only for what you need" manner.

[rossberg]

@askeksa-google, what you are saying isn't wrong (though I don't follow what you say re (2)). But as I argued before, this presentation is conflating two different types.

Conceptually, there are three different types at play here. Let's call them

• anyref (the type of all refs),
• externref (the type of all host refs),
• internref (the type of all proper wasm refs),

which is consistent with the current proposal. With that nomenclature, we'd have externref <: anyref as well as internref <: anyref. OTOH, internref and externref are incomparable (in fact, disjoint).

Now, there are altogether 8 design choices we can make for including or excluding each of these types. That includes the 4 you list, which are, modulo names:

Option (1): Only include externref.
Option (2): Include externref and anyref.
Option (3): Only include anyref (though named externref?).
Option (4): Include internref and anyref (renamed to anyref and externref, respectively).

Of course, there is also option (5): including all 3 types. And a few less interesting options.

So, the main thing I disagree with in this discussion is coupling these design choices with renamings that IMHO just confuse matters – if something is not a top type, then it can't be called any.