Under this JEP this code could be rewritten blindly into:
|switch (o) { case Number _ -> 1; case String _, Integer
_-> 2; } |
Under the definition of dead code above, the common case that was
grouped together,|-> 2|, is not dead anymore. It can be reached
via|*case String _*, Integer _-> 2|. As a result, the code above is
correct. It just happens that the sub-pattern|Integer _|will never be
reachable. This can be a warning but the overall case is correct.
An alternative interpretation would be to treat sub-patterns as "dead
code". Under that interpretation the second|case|of the second example
would be dominated because there is at least one preceding sub-pattern
(or whole case label with one pattern as in this case) that dominates
at least one of its sub-patterns (|Integer _|). That case could be
rejected (symmetrically to the first example). This seems restrictive
but also a valid direction.
So, my question is what would be the pros and cons of each approach?
Actually, it seems to me that you can rewrite the above as follows, even
w/o this JEP:
|switch (o) { case Number n -> 1; case String s, Integer i->
2; }|
If you do, the compiler complains, but not because `Integer i` is
unreacheable. But simply because we have fall-through between patterns.
This is defined in 14.11.1:
t is a compile-time error if there is a statement in a switch block
that consists of switch-labeled statement groups for which both of the
following are true:
1.
It is labeled with a switch label that introduces a pattern variable.
2.
There is a statement preceding it in the switch block and that
statement can complete normally (14.22
<https://docs.oracle.com/javase/specs/jls/se18/html/jls-14.html#jls-14.22>).
This condition is required to exclude the possibility of a switch
labeled statement being reached for which a pattern variable declared
in its switch label is in scope but without the pattern matching
having succeeded. For example, the statement labeled by the switch
label supporting the type pattern |Integer i| could be reached from
the preceding statement group, and so the pattern variable |i| will
not be initialized:
||
Now, you could make a case that the above restriction is unnecessary if
we have unnamed pattern binding variables... and _if_ you go down that
path, yes, you do end up with an issue when it comes to dominance.
But do we want to change the fall-through restriction?
Cheers
Maurizio
Many, thanks,
Aggelos
------------------------------------------------------------------------
*From:* Brian Goetz <[email protected]>
*Sent:* 26 January 2023 20:33
*To:* Angelos Bimpoudis <[email protected]>;
amber-spec-experts <[email protected]>
*Subject:* Re: Draft JLS Spec about unnamed patterns and variables
Small wording nit... in "an unnamed declaration can be used in place
of the following declarations"
I'm not sure "in place of" is the right wording; I think you may just
want to say "in", since the grammar permits it in all of these
places. (What you're really doing here is signalling that there are
places the grammar allows it, but the semantics do not; you are going
to call these out individually in the appropriate places.)
Similar for the second "in place of" in this section.
In 14.11.1, I might refactor the text a little further. The second
sentence of the first paragraph below is about case constants only,
but now comes after you talk about case patterns or case constants:
A|case|label has either one or more|case|constants, ora*one or
more*|case|pattern*s*. Every|case|constant must be either (1)
the|null|literal, (2) a constant expression (15.29
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29>),
or (3) the name of an enum constant (8.9.1
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1>);
otherwise a compile-time error occurs. A|case|label that has
a|null||case|constant may have an optional|default|.
It is a compile-time error if for any|case|label with more than
one|case|patterns, any of its|case|patterns declares one or more
pattern variables.
I suggest:
A|case|label has either one or more|case|constants, ora*one or
more*|case|pattern*s*.
/For a case label with case constants, /every|case|constant must be
either (1) the|null|literal, (2) a constant expression (15.29
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29>),
or (3) the name of an enum constant (8.9.1
<https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1>);
otherwise a compile-time error occurs. A|case|label that has
a|null||case|constant may have an optional|default|.
/For a case label with case patterns/, it is a compile-time error if
any of its|case|patterns declares one or more pattern variables.
I am not sure about the definition of dominance here. If I have:
case Integer _, String _: A;
case Number _ : B;
Number dominates Integer, but it doesn't dominate Integer|String. I
think you mean "if at least one of pi..pn dominates *all* of the
patterns ri..rm, no?
But I'm not even sure if this is the right formulation, because:
sealed interface I permits A, B { }
record A() implements I {}
record B() implements I {}
case A _, B _: ...
case I i: ...
The first case label dominates I. So I think you have to appeal to
exhaustiveness:
"A case label with case patterns p1...pm dominates another case label
with case patterns q1...qm if the set of patterns { p1..pm } dominates
each qi", no?
You probably have to slightly refactor the second statement about
"compile time error if dominance" accordingly.
On 1/26/2023 5:36 AM, Angelos Bimpoudis wrote:
Dear experts,
The first draft of the JLS spec about unnamed patterns and variables
(https://openjdk.org/jeps/8294349 <https://openjdk.org/jeps/8294349>)
is available at:
https://cr.openjdk.java.net/~abimpoudis/unnamed/latest/
<https://cr.openjdk.java.net/~abimpoudis/unnamed/latest/>
Comments very much welcomed!
Angelos
