Dominance in pattern matching for switch: Spec and Javac inconsistency

[Brian Goetz]

>
>     If I understand correctly, a guarded switch label effectively
>     can't dominate any other labels, since the spec doesn't go into
>     trying to statically analyze whether or not the guard could ever
>     be false.
>     I guess the spec could mention that (but it would be a comment,
>     since it follows from the other rules).
>
>
> A guarded switch pattern can not dominate any other guarded switch 
> pattern that have the same type pattern prefix,
> e.g.
>   case Integer i && foo(i)
> vs
>   case Integer i && bar(i)
>
> but a guarded switch dominates it's prefix,
> e.eg
>   case Integer i && foo(i) dominates case Integer.

You've got that backwards; `Integer i` dominates `Integer i && g` for 
all g.

> But there is no rule between a guarded pattern like case Integer i && 
> foo(i) and case 1, so they can appear in any order.

Correct, a type pattern `T` should dominate any constant case labels of 
type T, but you are right, thsi does not seem to work properly.

Also doesn't work with 17ea:

jshell> int x = 3; switch (x) { case Integer i:}
x ==> 3
|  Error:
|  the switch statement does not cover all possible input values
|   switch (x) { case Integer i:}
|   ^---------------------------^




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210903/93a65cd0/attachment.htm>