Elaborate on habitability of exact references

[tlively]

No description provided.

[tlively]

cc @sjrd and @rossberg

[sjrd]

That's very clear, thank you.

[rossberg]

Why not make the others uninhabited as well? With exn in particular there could in fact be motivation to introduce subtypes in the future (e.g., ones that disclose the tag's type or something like that). With i31 you could theoretically have subtypes that record something about the value range (e.g., fits a byte etc), although that seems unlikely. But I'd suggest not to take any chances, especially since I see no particular benefit in using these — they don't add any precision today.

[jakobkummerow]

Why not go yet another step further and disallow exact on abstract (i.e. non-indexed) references?

That would entirely rule out anyone relying on any specific behavior of exact abstract references, so it would have maximum forwards compatibility to any spec changes we might desire to make in the future.

For implementations consuming Wasm, enforcing this rule would be a pretty simple check in the decoder (even easier than enforcing that cont $x is only valid for $x being the index of a signature type); internal algorithms and data structures may bake in this restriction if they wish, and they are also free to assume that exact can apply to any ref type, even if the decoder won't actually let that happen. If an implementation makes this latter choice and also happens to produce Wasm, it'll need a comparably simple check in its backend: whenever it feels tempted to emit (ref exact <abstract>), it can just replace that with any other uninhabitable type, such as (ref none), or an unreachable instruction if this occurs in a code context.

(Taking a step back, I think as a general principle we should err on the side of disallowing things that have no use case, rather than allowing them "for consistency". Having to support nonsensical/unused things, in general, adds significant complexity. We can always relax such restrictions later (or lift them entirely) if use cases arise.)

[rossberg]

@jakobkummerow, see the discussion on #9.

[jakobkummerow]

@rossberg yes, what about it? Consensus in that discussion was that exact abstract types are both harmless and useless. I'm asking why we don't just drop them on account of their uselessness. That would certainly address the concerns in your previous post about exn and i31.

[rossberg]

That also was the question we discussed there.

[tlively]

I support having a more in-depth discussion about whether we should allow exact references to abstract types at all. Thanks for opening #15, @jakobkummerow.

While that conversation is pending, I will update the overview to say that (ref exact {i31,exn,waitqueue}) are uninhabited as well. I still think we need to update ref.null to produce an exact reference so ref.null none produces (ref null exact none) and can be used in locations that expect a (ref null exact $Foo).

[tlively]

I opened #16 to make this change.