Fw: JEP 455: Non-enhanced switch statements
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Oct 27 13:56:26 UTC 2023
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>
More information about the amber-spec-experts
mailing list