Generalize the binary shorthand for exact references #9
Conversation
Extend the pattern of using `0x62 ht:absheaptype` as a shorthand for nullable reference types beyond just abstract heaptypes. Instead, use `0x62 ht:heaptype` to mean a nullable exact reference for any heap type, replacing the previous encoding. Keep the `(exact anyref)` text shorthand for abstract heap types, but do not extend it to other heap types since it is generally not as readable as an explicitly spelled out type.
|
In practice I've found that the |
|
Is there reason to assume that nullable exact types are more frequent than non-nullable ones? That is a bit counter-intuitive to me. Otherwise, you'd rather want to shorten the other one. I'm on board with not supporting the |
No, I haven't done any measurements. This made sense when it just applied to abstract heap types because we already only have binary shorthands for their nullable references. Reserving the shorter encoding for the more common pattern sounds good to me. I'll add a note in the text reminding us to revisit this later once we have implementations. |
|
IMO,
One very concrete constraint is that we would never be allowed to add subtypes of For struct types, it's OK. We can reasonably assume that if we ever add new subtypes of struct types, values of such types would be completely new; not values that exist today. For broad types like |
|
This is addressed in the overview:
This is intended to apply to every abstract heap type that does not specifically have values. I think the only exceptions are |
|
I agree that exact abstract types are rather useless. But they are also harmless — both is true because they are uninhabited. We'd only get into trouble if we broke that invariant and introduced an instruction that produces a value of such a type. But I see no reason why we would ever want to, since that's equally useless AFAICS. @tlively, maybe it's worth spelling out this invariant more explicitly? So yeah, we could make special cases and disallow exact abstract types. But is it worth the effort? Btw, I still think calling them "final" fits in better with the existing language... |
Ah, I had missed that. Indeed, if they are uninhabited, and are guaranteed to stay uninhabited forever, then it's harmless. And if it helps regularity, that's a good motivation not to forbid them. |
|
This is made obsolete by #18. |
Extend the pattern of using
0x62 ht:absheaptypeas a shorthand fornullable reference types beyond just abstract heaptypes. Instead, use
0x62 ht:heaptypeto mean a nullable exact reference for any heap type,replacing the previous encoding.
Keep the
(exact anyref)text shorthand for abstract heap types, but donot extend it to other heap types since it is generally not as readable
as an explicitly spelled out type.