rtt implied by ref.func

[manoskouk]

What rtt is implied when allocating a function with ref.func? E.g., how does the following code work?

(type $bar_type ...)
(function $bar (type $bar_type) ... )
(function $foo (type ...) (local funcref) (
  (local.set 0 (ref.func $bar))
  (ref.test (local.get 0) (rtt.canon $bar_type)))

[rossberg]

Ah, it's supposed to be the canonical RTT for the function's type, i.e., the test should succeed. I added the missing bullet.

[jakobkummerow]

Just to clarify: IIUC, that means that using rtt.sub with function RTTs is legal but useless, as any custom sub-RTTs created that way can't be used to create any references, because there is no ref.func_with_rtt (akin to struct.new_with_rtt).

Also, this means that function references created with ref.func can't be ref.casted from anyref to funcref, because their RTT is not a sub-RTT of the funcref RTT. (This is similar to i31ref not being downcastable from anyref to eqref.) I personally don't have any objections to this limitation, though I do wonder whether there are any real-world use cases that would find this inconvenient.

[RossTate]

@rossberg Your answer here contradicts the MVP document, which says that rtt.is_func would be equivalent to (rtt.canon func) (ref.test). This issue should probably be reopened.