Dominance in pattern matching for switch: Spec and Javac inconsistency

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Jesper Steen Møller"
> <jesper at selskabet.org>
> Cc: "Ilyas Selimov" <ilyas.selimov at jetbrains.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Vendredi 3 Septembre 2021 22:07:57
> Subject: Re: Dominance in pattern matching for switch: Spec and Javac
> inconsistency

>>> 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.
yes ! 

>> 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:}
> | ^---------------------------^
About the relation between int and Integer, the spec allows boxing but not unboxing, i wonder if we enhance the spec to support unboxing, 
unboxing being like a pattern query with two possible outcome: do not match if null and match and extract the value if non null. 

Integer anInteger = ... 
switch(anInteger) { 
case null -> // called if null 
case int i -> // called for non null Integer 
} 

and 
Integer anInteger = ... 
switch(anInteger) { // NPE if null 
case int i -> // called for non null Integer 
} 

with case Integer dominating case int. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210904/fbc4dcfc/attachment-0001.htm>