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 <[email protected]>
*Sent:* 24 October 2023 21:57
*To:* Angelos Bimpoudis <[email protected]>
*Cc:* [email protected] <[email protected]>
*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;
}
