Dominance in pattern matching for switch: Spec and Javac inconsistency

[forax at univ-mlv.fr]

> From: "Jesper Steen Møller" <jesper at selskabet.org>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Ilyas Selimov"
> <ilyas.selimov at jetbrains.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Vendredi 3 Septembre 2021 10:30:58
> Subject: Re: Dominance in pattern matching for switch: Spec and Javac
> inconsistency

> Hi

Hi, 
moved to spec-expert because there is an open question at the end, 

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

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. 

We may want to revisit that because from my own experience, it's not rare to add/remove guards to a pattern during the development, 
so forcing case 1 to dominate case Integer i && foo(i) means that you do not have to re-organize the case when you remove the guard. 

But I don't know if it's a good idea or not ? 

> -Jesper

Rémi 

>> On 3 Sep 2021, at 09.29, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>>> From: "Ilyas Selimov" < [ mailto:ilyas.selimov at jetbrains.com |
>>> ilyas.selimov at jetbrains.com ] >
>>> To: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net |
>>> compiler-dev at openjdk.java.net ] >
>>> Sent: Vendredi 3 Septembre 2021 07:27:42
>>> Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency

>>> Hello!

>>> The next code compiles correctly, but it seems to contradict the dominance
>>> rules:

>>> void test(Integer i) {
>>> switch (i) {
>>> case Integer in && in != null:
>>> break;
>>> case 1:
>>> break;
>>> case default:
>>> break;
>>> }
>>> }

>>>> A switch label that has a pattern case label element p dominates another switch
>>>> label that has a constant case label element c if either of the following is
>>> > true:
>>>> - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype
>>> > of the erasure of the type of p.

>>> Maybe the type of p should also be total for the type of selector expression
>>> like in the rules for pattern-over-null dominance?

>> For me, the problem comes from the guard, if you write the same code without the
>> guard, the compiler correctly emits an error
>> void test(Integer i) {
>> switch (i) {
>> case Integer in:
>> break;
>> case 1:
>> break;
>> case default:
>> break;
>> }
>> }

>> for me, this rule should apply even if p is a guard, the type of p when p is a
>> guard is the type of the type part (the left part) of a guard.

>> So it's more a bug in the implementation than a spec issue.
>> But given that Eclipse has the same issue, the spec should be clarified.

>>> Thanks,
>>> Ilyas

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