Exhaustiveness for record pattern with switch (JEP 440+441)

[David Alayachew]

Definitely agreed.

On Fri, Jul 7, 2023 at 4:34 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Looks like a bug too me,
> the possible combinations are (C, C), (C, D) (D, C) (D,D), they are all
> covered.
>
> Rémi
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"Mikhail Pyltsin" <pyltsinm at gmail.com>
> *Cc: *"compiler-dev" <compiler-dev at openjdk.org>, "amber-dev" <
> amber-dev at openjdk.org>
> *Sent: *Friday, July 7, 2023 10:43:26 PM
> *Subject: *Re: Exhaustiveness for record pattern with switch (JEP 440+441)
>
> I've CC'd the Amber Dev Team.
>
> On Fri, Jul 7, 2023 at 1:52 PM Mikhail Pyltsin <pyltsinm at gmail.com> wrote:
>
>> Hi!
>> I investigated the algorithm, which Javac 21 (Build 30 (2023/7/6))
>> ) uses to check exhaustiveness for record patterns (JEP 440+441), and
>> found the strange behavior:
>> - let's take compilable code
>> ```
>> class Test22 {
>>
>>   record Pair(I i1, I i2) {}
>>
>>   sealed interface I {}
>>
>>   record C() implements I {}
>>
>>   record D() implements I {}
>>
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(C fst, D snd) -> {
>>       }
>>       case Pair(C fst, C snd) -> {
>>       }
>>       case Pair(I fst, C snd) -> {
>>       }
>>       case Pair(D fst, D snd) -> {
>>       }
>>     }
>>   }
>> }
>> ```
>> - If we swap types of components, it starts to produce the error "java:
>> the switch statement does not cover all possible input values":
>> ```
>>   void exhaustinvenessWithInterface(Pair pairI) {
>>     switch (pairI) {
>>       case Pair(D fst, C snd) -> {
>>       }
>>       case Pair(C fst, C snd) -> {
>>       }
>>       case Pair(C fst, I snd) -> {
>>       }
>>       case Pair(D fst, D snd) -> {
>>       }
>>     }
>>   }
>> ```
>> It happens because Javac tries to find the first distinguished type from
>> the beginning, but I couldn't find any mention of it in JEP.
>> Is this the expected behavior?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230707/187991ca/attachment.htm>