AW: switch exhaustiveness check not working within deconstruction pattern.

[Remi Forax]

> From: "Red IO" <redio.development at gmail.com>
> To: "jan lahoda" <jan.lahoda at oracle.com>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, November 14, 2022 9:42:00 PM
> Subject: AW: switch exhaustiveness check not working within deconstruction
> pattern.

> I use VSCode with the “Extension Pack for Java”.

> I back checked on my (still linting) code using javac directly and it’s in fact
> not an error there.

> I assumed the (error) linting of the VSCode extension was based on javac output.
> But I guess it’s a bug in their own code checking system unrelated to javac
> output.

> I will open an issue on the extension instead.

> Sorry to bother you and take your time for this.

The linting in VSCode is based on ecj, the eclipse compiler so it seems there is a bug in ecj. 

> Great regards

> RedIODev

regards, 
Rémi 

> Von: Jan Lahoda <jan.lahoda at oracle.com>
> Gesendet: Montag, 14. November 2022 12:41
> An: redio.development at gmail.com; amber-dev at openjdk.org
> Betreff: Re: switch exhaustiveness check not working within deconstruction
> pattern.

> Hi,

> This should indeed be exhaustive, AFAIK, and javac from JDK 19 seems to be happy
> with the code:

> ---

> $ ./javac --enable-preview -source 19 /tmp/Main.java

> Note: /tmp/Main.java uses preview features of Java SE 19.
> Note: Recompile with -Xlint:preview for details.

> ---

> What are the precise steps to reproduce/JDK version?

> Thanks,

> Jan

> From: amber-dev < [ mailto:amber-dev-retn at openjdk.org |
> amber-dev-retn at openjdk.org ] > on behalf of [
> mailto:redio.development at gmail.com | redio.development at gmail.com ] < [
> mailto:redio.development at gmail.com | redio.development at gmail.com ] >
> Sent: Sunday, November 13, 2022 6:48 PM
> To: [ mailto:amber-dev at openjdk.org | amber-dev at openjdk.org ] < [
> mailto:amber-dev at openjdk.org | amber-dev at openjdk.org ] >
> Subject: switch exhaustiveness check not working within deconstruction pattern.

> package dev . redio ;

> import static dev . redio . Main . Activity .*;

> public class Main {

> public static void main ( String [] args ) {

> record Pair ( boolean weekend , Activity activity ) {}

> var pair = new Pair ( true , new Sleeping ( 8 ));

> var msg = switch ( pair ) { // <- A switch expression should have a default case
> Java(1073743531)

> case Pair ( boolean b , Sleeping s ) -> "3" ;

> case Pair ( boolean b , Skiing s ) -> "4" ;

> case Pair ( boolean b , Coding c ) -> "5" ;

> };

> System . out . println ( msg );

> }

> sealed interface Activity {

> record Sleeping ( int hours ) implements Activity {}

> record Skiing ( String resort ) implements Activity {}

> record Coding () implements Activity {}

> }

> }

> This deconstruction should be exhaustive since Pair is a guaranteed match
> boolean doesn’t have subclasses and Activity is sealed and fully covered.

> Null should throw in this case. A default case would never be reached.

> (Compiling and running with (dead) default case)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221115/93cbec28/attachment.htm>