idea for interaction with ref.cast

[lukewagner]

Thinking about callee-checked call tags vs. caller-checked casting from funcref to typed function references via ref.cast, both seem valuable for optimizing different cases. The former can efficiently capture situations like interface dispatch, as presented. The latter can allow a type check to hoisted so it is performed once, followed by multiple typed (unchecked) calls.

It seems like one can support both by specifying:

• call tags are unified with the GC proposal's rtts, factoring them out of the GC proposal if necessary
• functions can be given explicit tags, which also seems to be a common theme between this proposal and gc/#99
• there is a new way to define a function (with type funcref) as an "overload set" of N other functions (i.e., dispatch_func from #1346)
• funcrefs can be downcast via ref.cast
  • for the overload-set case, the list of functions is scanned and the cast succeeds if any match the given rtt
• there is a new variant of call_indirect for passing an rtt (call_funcref from #1346)
  • for the overload-set case, the call succeeds if it matches any of the N functions' rtts
  • for the normal case, the call succeeds if it matches the functions' rtt
• the existing call_indirect $t behaves as if using the new call_indirect variant, passing rtt.canon $t, which means it also works for overload sets

I think it would be possible to implement this feature with purely caller-side checking (reducing the two call_indirect variants into a ref.cast followed by call_ref), but I think it would be somewhat more efficient for the implementation to implement the two call_indirects as a callee-side check. In any case, to support ref.cast on an overload-set funcref, the implementation would need to have the list of rtts efficiently reachable from the funcref, which seems doable.

Anyhow, this is just a sketch of an idea for how to achieve both of these goals. Maybe I'm neglecting some details.

[RossTate]

So here's what I was thinking for how one would bridge untyped function references (i.e. funcref) and typed function references.

First, have an instruction like get_callee $ct : [funcref] -> [(ref (func (param ti*) (result to*)))], where call_tag $ct : [ti*] -> [to*]. This takes a funcref and returns the typed function reference it would call if given call tag $ct.

Note that, with func_switch (I renamed dispatch_func, and I'm still open to suggestions), the typed function reference resulting from get_callee might not be the same reference as the untyped function reference. And with the ability to define a function with no call tags, it might not make sense to expect typed function references to have a corresponding untyped function reference (if someone makes a funcref using its index, the engine could just provide some singleton funcref that always traps). Plus, even without call tags, we already know that an indirect call to a typed function reference might not succeed even with the signature of its type.

These observations suggest to me that typed function references and untyped function references are distinct kinds of values, and consequently there's no subtyping relationship between these types. This observation is in line with the research on mixing sound typed and untyped functions. It also means that a typed function reference can be simply a pointer to assembly code that expects arguments of the given type and returns values of the given type.

[lukewagner]

Ok, makes sense. It looks like the main difference is the broader question about function reference subtyping.

[RossTate]

Possibly. As I said, you can have both if you really want to.

[RossTate]

Hmm, I came across another way to look at the difference between rtts and call tags.

Rtts are positive tags whereas call tags are negative tags. That is, the differ in who first commits to choosing what the cast should be and who can switch on that choice. With rtts, the castee first commits, and the caster can switch on that choice. With call tags, the caster first commits, and the callee can switch on that choice.

Interestingly, since most types are positive, it seems to turn out that positive tags are the better fit for most data. But as functions are negative, it seems to turn out that negative tags are the better fit for them. I can't explain why that is, but it's an interesting observation.

Either way, this suggests that rtts and call tags really are distinct concepts, which makes me concerned that attempts to combine them into one will not fair well.