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

[Brian Goetz]

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.