> On May 17, 2023, at 11:25 AM, Brian Goetz <[email protected]> wrote: > > > > On 5/17/2023 8:33 AM, Remi Forax wrote: >> Hello, all, >> I've reread the JEP 443, >> >> https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html >> >> First, a minor nit, at the end of the section 14.30.1, there is this >> sentence that reference the section 14.30.1 ! >> "An unnamed pattern is always null-matching (14.30.1)." >> >> My brain, stackoverflowed on that :) > > This is a minor shuffling of terminology, but nothing really has changed. > > Previously we recorded the difference between a partial and total type > pattern (which differ at their null matching) through a process of resolving > an unconditional pattern to an "any" pattern. The any pattern was a figment > of the specification, and didn't correspond to anything in the language > (yet). Now that we have underscore patterns, which might well be called > "any" patterns, the terminology was confusing so we adjusted the terms, to > those that will likely serve us better in the future. But the semantics are > still what they always were. > >> And now a question, with the introduction of the unnamed pattern, in a >> switch, "case _" and "case null, default" have the same semantics, >> given that "case null, default" is a kind of a hack, should we still allow >> it ? >> > > This is actually two questions: > > - should we still allow `case null, default` (current answer: yes) > - should we allow `case _` (current answer: no) > > If the answer to the second is no, there is no question that we should > continue to say yes to the first. > > I think given the long history of null-hostility of switch, giving people > both `case _` and `default` at the top level will make more trouble than it > solves, so the status quo seems OK to me.
Yes, for the rare cases where one needs to say it, the purpose of "case null, default:” will be easier to understand for most readers than “case _:”.
