Fw: JEP 455: Non-enhanced switch statements

[Maurizio Cimadamore]

I think I agree. While coupling the notion of enhanced swith with that 
of exhaustiveness has been a good way to define some kind of line 
between old and new behavior, I think it might perhaps be wiser to 
enforce exhaustiveness on a more data-dependent way - e.g. what is the 
type we're switching on? If it's an enum, or a sealed class, I see some 
value in enforcing some kind of exhaustiveness analysis. But for strings 
and numbers, it is not clear to me that enforcing exhaustiveness at the 
statement level makes sense.


Sure, if I define a class that interprets all the JVM bytecodes, I could 
always forget to handle one of them if my interpreter logic is a big int 
switch.


But perhaps, in such cases, we would suggest a design where the opcodes 
are modelled using records implementing a single sealed interface, or 
some enum (thereby also getting exhaustiveness checks for free) ?


Unfortunately enum is that one case where compatibility dictates that we 
can't be exhaustive, which is a little sad... but I think that's the 
best we can do?

Maurizio


On 24/10/2023 23:49, Angelos Bimpoudis wrote:
> Hello all!
>
> Yuriy pointed out a valid point.
>
> 1) Should we treat float/double/boolean/longs as a new addition to the 
> non-enhanced switch (old switch) and support anything new that comes 
> with that?
>
> or
>
> 2) Should we treat those data types equally with all the pre-existing 
> ones?
>
> I am strongly in favour of the 2) for the shake of symmetry and 
> uniformity in what the user will assume, thus I will fix the bug.
>
> What do others think?
>
> ------------------------------------------------------------------------
> *From:* Yuriy Maslyanko <yuriy.maslyanko at oracle.com>
> *Sent:* 24 October 2023 21:57
> *To:* Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
> *Cc:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>
> *Subject:* JEP 455: Non-enhanced switch statements
>
> Hi Angelos,
>
> Section 14.11.2 of 
> https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 
> <https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2> 
> has this note:
>
> For compatibility reasons, |switch| statements that are not enhanced 
> |switch| statements are not required to be exhaustive.
>
> Noticed that if the switch selector statement is float/double/boolean 
> (in this case it’s a non-enhanced switch statement), the code shown 
> below fails with “error: the switch statement does not cover all 
> possible input values”:
>
>     static boolean check = false;
>
>     public static boolean testMethod() {
>
>         double v1 = 1d;
>
>         switch ( v1 ) {
>
>             case 1d:
>
>                 check = true;
>
>                 break;
>
>         }
>
>         return check;
>
>     }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20231027/978ee737/attachment.htm>