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:}
| ^---------------------------^
