Dominance in pattern matching for switch: Spec and Javac inconsistency
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Sep 3 14:00:20 UTC 2021
> 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>
More information about the amber-spec-experts
mailing list