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
