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.
