JEP 443: semantics of "case _" vs "case null, default"

[Guy Steele]

> On May 17, 2023, at 11:25 AM, Brian Goetz <brian.goetz at oracle.com> 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 _:”.