> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Tagir Valeev" <amae...@gmail.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Sent: Thursday, January 27, 2022 4:41:27 PM > Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing > feedback on patterns in switch)
>> In that case, i prefer the current semantics because it's the same if a >> pattern >> is a top-level or not. > I wish people could keep these things straight. We’re not talking about > changing > the semantics of how pattern matching works, which patterns match what, what > nesting means, etc. We’re simply talking about the *boundary* between a > specific pattern-accepting construct, which has pre-existing value filtering > opinions, and the patterns it accepts. > The current (preview) boundary says: > - If a switch has a `case null`, or a total pattern, a null value matches > that, > otherwise we throw NPE on null, and for non-null, it is matched to the > patterns > in the case labels. > The adjusted boundary says: > - If a switch has a `case null`, a null value matches that, otherwise we throw > NPE on null, and for non-null, it is matched to the patterns in the case > label. > So this adjusts *which* patterns the switch lets see null values. Previously, > it > was “none”; in the current preview, it is “case null and total patterns”, and > the adjustment proposed is “case null”. The latter is a tradeoff to avoid > confusing the users, who currently believe switch always throws on null, by > saying “switch accepts null if it says case null.” > We currently have a similar problem with `intsnaceof`, where we disallow total > patterns on the RHS of instanceof. We would adjust in the same way: instanceof > always says false on nulls, and tests against the RHS on non-null. > Nothing to do with the semantics of pattern matching. Total patterns are still > total. You can say you only change the semantics of switch not the semantics of pattern matching, but the idea that you can separate the two is confusing. For me, the semantics of pattern matching change because currently a total pattern always match null, whatever its position, as top-level or inside a record pattern (for example), with the semantics you propose a top-level pattern will not match null anymore but will match null if nested. So yes, i suppose you can say that the semantics of a total pattern is not changed because whatever the position it *can* match null, but 'm not sure this way of thinking helps. To make thing super clear, with the current semantics, "case Object o" always match null, with your proposal, the answer is it depends if it is nested or not. That's why i prefer the current semantics. regards, Rémi PS: the feedback about the fact that it's not clear if a switch allows null or not can also be seen as a symptom of the fact that the notion of total pattern is not obvious for everybody (and having no syntax hint does not help).
