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

tjmnkrajyej at gmail.com tjmnkrajyej at gmail.com
Sat Sep 24 18:40:58 UTC 2022


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/73317df7/attachment-0001.htm>


More information about the amber-dev mailing list