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

[Remi Forax]

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 < [ mailto:pyltsinm at gmail.com |
> 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/amber-dev/attachments/20230707/9cca413c/attachment.htm>