[patterns] Domination in guarded multiple pattern labels

[Angelos Bimpoudis]

Hello hello :-)

I agree with you that both cases should not be valid. Regardless of the presence of a guard, if intra-case dominance is violated, the switch needs to be rejected. This is a compiler bug. Good catch 🚀

I think, the intra-case dominance is covered by the following rule at the spec (pasting):
It is a compile-time error if in a switch block there is a case label with case patterns p1,...,pn (n > 1) where one of the patterns pi (1 ≤ i < n) dominates another of the patterns pj (i < j ≤ n).
Is this what you had in mind?

Many thanks and best regards,
Angelos

________________________________
From: amber-spec-experts <amber-spec-experts-retn at openjdk.org> on behalf of Tagir Valeev <amaembo at gmail.com>
Sent: 18 August 2023 11:48
To: amber-spec-experts <amber-spec-experts at openjdk.org>
Subject: [patterns] Domination in guarded multiple pattern labels

Hello!

Consider the following code:

public class Test {
    void test(Object obj) {
       switch (obj) {
          case Integer _, CharSequence _, String _ when obj.hashCode() > 0 -> {
          }
          default -> throw new IllegalStateException("Unexpected
value: " + obj);
       }
    }
}

Javac compiles it, despite the `String _` pattern being unreachable.
It looks like the spec [1] allows it. It speaks about domination of
case labels, but not about the domination of individual patterns
within the case label. I think this part should be improved. Namely,
for several patterns under the single case label, domination rules
must apply, and the guard must be ignored.

It's interesting that if we remove the guard, the compilation fails:

Test.java:4:45
java: this case label is dominated by a preceding case label

While formally according to the spec, this should be accepted, as spec
in its current shape says us only about 'preceding case label', and
there's no preceding case label at all, so the first label should not
be dominated.

With best regards,
Tagir Valeev

[1] https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html#jls-14.11.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230819/fcbc2741/attachment-0001.htm>