Switch labels (null again), some tweaking

[Maurizio Cimadamore]

On 23/04/2021 16:38, Brian Goetz wrote:
> So, I think the "a switch only accepts null if the letters n-u-l-l are 
> present", while a comforting move in the short term, buys us 
> relatively little, and dulls our pain receptors which in turn makes it 
> take way longer to learn how patterns really work.  I think we should 
> go back to:
>
>  - A switch accepts null if (a) one of the case labels is `null` or 
> (b) the switch has a total pattern (which must always be the last case.) 

The proposal seems ok; it does nothing for the problem I'm concerned 
about (e.g. type of the target expression changing and influencing the 
totality analysis at a distance) - but that was not address by the 
previous proposal either (as you say in your email, admittedly, I was 
reading too much into your proposal).

Stepping back - my general feeling on this topic is that the audience in 
this mailing list have a very intimate knowledge of what a "total 
pattern" is, to the point that they are comfortable building on top of 
this definition to e.g. define null behavior of patterns. I'm a little 
afraid that the finer detail of totality might be lost on the average 
Joe developer: totality is a much more slippery concept than it seems. 
Sure, there is one obvious way to make your pattern total: if the target 
expression has type E, then add a type test pattern whose type is also 
E. That seems easy enough. Except that, the type of E will not always be 
that manifest in user code (e.g. might be the result of what javac 
happens to infer on Tuesdays). And, if you mix this with sealed classes, 
it might be possible for a switch to go from total to non-total, as new 
permitted subtypes are added to a sealed hierarchy. These might all be 
all corner cases - but I think it's this complexity which contributes to 
my "isn't this all too subtle?" feeling.

Obviously I'm well aware that nearly every path has been explored, and 
no silver bullet seems to be laying around, so... this might just be the 
best we can offer, and that's ok.

Cheers
Maurizio



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210427/1f4a8afa/attachment.htm>