> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Sent: Wednesday, February 16, 2022 3:48:14 PM > Subject: Re: [External] : Re: Reviewing feedback on patterns in switch
>> 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. I think it will be more clear when we will introduce patterns on local variable declaration because those will only allow some patterns but not all. > 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. It's not about how people like it but how people rationalize it. You can say "switches throw on null unless the letters n-u-l-l appear in the switch body" or "switches throw on null unless a null-friendly pattern appear in the switch body and this is also true for nested patterns". Both are valid approach. Rémi
