Allow cont ref to be non-null in switch

[fgmccabe]

Actually, if you want to be consistent with BoS, the switch instruction should not take a nullable cont as argument. There does not seem to be any situation where null is a reasonable argument for switch.

OTOH, if we decide on a retire instruction then it will generate a null; which means that the target of a switch might be null; but that can be encoded in t2*

[tlively]

For better or worse, there is no precedent for an instruction requiring one of its inputs to be non-null. All instructions that might do so (e.g. any accessor like struct.get or array.set) instead accept nullable inputs and trap when the input is null at runtime. For consistency with the rest of the language, switch should also accept a nullable continuation reference.

[tlively]

That being said, this PR is not correct or necessary. The typing rules give the most general possible type for an instruction and subsumption separately allows the input types to be refined. switch $ct1 $e : [t1* (ref null $ct1)] -> [t2*] already allows the input continuation to be non-nullable because (ref $ct1) <: (ref null $ct1).

[Alan-Liang]

Then perhaps we should change all instruction signatures in the proposal to receive a nullable reference, instead of a null?able reference?

This includes cont.new, cont.bind, resume and resume_throw.

[rossberg]

Yes, it's probably an oversight (or simplification) that they don't in the Explainer, they do in the implementation.

[slindley]

IIRC, it came from writing down simplified typing rules that do not rely on subtyping. We still give such rules initially in the explainer and then the full rules with subtyping at the end of the explainer.