Bad exhaustive test using Record Pattern as delivered in OpenJDK 19 preview

[tjmnkrajyej at gmail.com]

Despite what I said in my last mail, the first switch that I showed 
augmented with a default case seems to execute the Some<String> case 
anyway—which produces a ClassCastException—so the default case seems to 
be redundant during runtime albeit required during compilation.

Option<String> option = new Some(new Object());
     switch (option) {
         case Some<String>(var value) -> System.out.println(value);
         case None<String>() -> System.out.println("none");
         case default -> System.out.println(option);
     }

So I agree with you: there seems to be a bug.

> I see. I apologize for my ignorant comment. After some 
> experimentation, I've discovered that the switch compiles when the 
> component of Some (value) is destructured with the type Object instead 
> of String. Since we currently don't have generic reification, any 
> Option<String> can be cast to Option<Object> successfully at runtime 
> ((Option<Object>) (Object) optionString); which means that the error 
> that you have shown is probably for preventing cases like the one below.
>
> Option<String> option = new Some(new Object());
>     switch (option) {
>         case Some<String>(var value) -> System.out.println(value);
>         case None<String>() -> System.out.println("none");
>     }
>
> Additionally, the compiler seems to deem the following code snippet valid.
>
> Option<String> option = new Some("some");
>     switch (option) {
>         case Some<?>(var value) -> System.out.println(value);
>         case None<String>() -> System.out.println("none");
>     }
>
> The interesting thing about it is that the type argument in the case 
> of None appears to be insignificant to the compiler so long as it's 
> assignable to String.
>
>> Hello sir,
>>
>> Thank you for your attention.
>>
>> As I recall, « switch » without explicit null cases do not accept nulls.
>>
>> I enriched the failing cases here and included commands ran and their 
>> output : https://gist.github.com/grimly/1cc1228feacb51eaef59bfea86d2add5
>>
>> In the gist above, the « TestFailing » file throws as I would expect 
>> by the missing null case.
>>
>> Adding the null case in « TestFailing2 » didn’t help either.
>>
>> Best regards,
>>
>> Michel
>>
>> *From: *tjmnkrajyej at gmail.com
>> *Sent: *vendredi 23 septembre 2022 17:55
>> *To: *Michel Turpin <mailto:michel.turpin1 at gmail.com>; 
>> amber-dev at openjdk.org
>> *Subject: *Bad exhaustive test using Record Pattern as delivered in 
>> OpenJDK 19 preview
>>
>> `opt` can be `null`.
>>
>>     Hello,
>>
>>     First, please excuse me for the way I send this bug report. I
>>     cannot find a way to report it in other ways.
>>
>>     Looking at the description of JEP 405, it made me think of Rust
>>     enums and pattern matching.
>>
>>     I tried then to play on how to write a copy of the Rust "Option"
>>     enum :
>>     https://gist.github.com/grimly/55d414f0cc3395e87a7c813176c50ac9
>>
>>     But then I encountered this issue when narrowing the types I use
>>     and in this particular instance (
>>     https://gist.github.com/grimly/55d414f0cc3395e87a7c813176c50ac9#file-testfailing-java-L9-L12
>>     ), the compiler throws an error and reports the switch is not
>>     exhaustive.
>>
>>     Given in my code "Option" is sealed and may only be "Some" or
>>     "None", I would expect listing both options to make my cases
>>     exhaustive.
>>
>>     Adding a default case, I also fail to produce an instance that
>>     would trigger it.
>>
>>     Best regards,
>>
>>     Michel
>>
>>
>>     -- 
>>
>> Michel TURPIN
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220924/5d4940f5/attachment.htm>