Not sure it's a no-brainer.
The question is more a question of consistency. There are two consistencies and we have to choose one, either switch never allows null by default and users have to opt-in with case null or we want patterns to behave the same way if they are declared at top-level or if they are nested. I would say that the semantics you propose is more like the current Java and the other semantics is more like the Java of a future (if we choose the second option).

You are right that any justification involving "for consistency" is mostly a self-justification.  But here's where I think this is a cleaner decomposition.

We define the semantics of the patterns in a vacuum; matching is a three-place predicate involving a static target type, a target expression, and a pattern.  Null is not special here.  (This is how we've done this all along.)

Pattern contexts (instanceof, switch, and  in the future, nested patterns, let/bind, catch, etc) on the other hand, may have pre-existing (and in some cases reasonable) opinions about null. What's new here is to fully separate the construct opinions about special values from the pattern semantics -- the construct makes its decision about the special values, before consulting the pattern.

This lets instanceof treat null as valid but say "null is not an instance of anything", past-switch treats null as always an error, and future-switch treats null as a value you can opt into matching with the `null` label.  (Yes, this is clunky; if we had non-nullable type patterns, we'd get there more directly.)

But the part that I think is more or less obvious-in-hindsight is that the switch opinions are switches opinions, and the pattern opinions are pattern opinions, and there is a well-defined order in which those opinions are acted on -- the construct mediates between the target and the patterns.  That is, we compose the result from the construct semantics and-then the pattern semantics.

None of this is really all that much about "how do people like it". But what I do think people will like is that they get a simple rule out of switches: "switches throw on null unless the letters n-u-l-l appear in the switch body".  And a simple rule for instanceof: "instanceof never evaluates to true on null".  And that these rules are *independent of patterns*.  So switch and instanceof can be understood separately from patterns.

Reply via email to