Should rtts be normal references?

[manoskouk]

Hello,
in #96 it was discussed that rtts should be separate from ref types, but this decision got reversed in 1be5d78. @rossberg could you please explain the rationale for this? Specifically, is there a use case where we will want to use an rtt value in an anyref context?

[rossberg]

The original motivation for this change no longer applies, since the type argument to rtt is no longer a heap type, but specifically a type index – a consequence of the refactoring of casts in #150. So nested RTTs can no longer arise.

At the same time, the special status of RTTs turned out to be quite problematic. I remember at least two problems:

1. Not being references, RTT types weren't nullable anymore. Hence it was not possible to have a local or uninitialised global (or a table) of RTT type. That would have been a showstopper, at least in my compilers.

2. Their special status in the type system as neither numeric nor reference required extra rules and special cases in various places of the type system.

So without the motivation for making them special gone, and the new problems it created, it seemed like an obvious win to back out of that change. (IIRC this was supposed to happen with #150, but there were several oversights I fixed later.)

[rossberg]

Sorry, forgot to address your last question. No, I don't have a use case, it just was the natural thing to do. If it should be problematic, we can of course discuss removing the rtt $t <: any subtyping rule. That's separable from the rest.

[manoskouk]

Thanks for the explanation! Having them be refs is fine. I have a slight concern with rtt $t <: any: since rtts have constraints regarding their runtime representation to be compatible with type descriptors, casting down to (specific) rtts may be slow, or may require changing the representation of type descriptors. It wouldn't be impossible, of course, and we should allow it if there is a use case, but otherwise we should consider dropping it.

[rossberg]

Oh, having that subtype relation does not imply that you can cast down the other way. There is currently no instruction that would enable you to do so. And that is not an accident, I agree that it's not something we'd need or want.

[manoskouk]

There is currently no instruction that would enable you to do so.

Right, I was thinking in terms of #274, where there this would be possible unless we explicitly disallow it.