Dominance in pattern matching for switch: Spec and Javac inconsistency
Brian Goetz
brian.goetz at oracle.com
Fri Sep 3 20:07:57 UTC 2021
>
> 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>
More information about the amber-spec-experts
mailing list