Thanks for bringing this up. I remember it being discussed once before,
but I don't think we acted on it.
I agree that expression switch is an expression, and it should either
yield a value or throw something; breaking out of the middle of an
expression is not something we have, nor does it seem necessary. (Though
I'm sure clever folks could come up with a good example where it would
be convenient.)
A sensible extension of this is no "return" from a switch expression either:
int foo(int x) {
return switch (x) {
case 1 -> 2;
case 2 -> 4;
case 3 -> 8;
default: return Integer.MAX_VALUE;
}
}
Like conditionals, then, switch expressions would either yield a value
(through breaking) or throw. This seems consistent, but...what happens
when we nest a statement in a switch expression?
void foo(int x, int y, int z) {
TOP:
switch (z) {
case 1:
int i = switch (x) {
case 1 -> 2;
case 2:
switch (y) {
case 1: return;
default: break TOP;
}
}
}
}
Do we disallow the "break TOP" and return in the inner switch? IOW, does
the expression form a barrier through which control can only pass via
break or exceptions?
On 3/2/2018 9:30 AM, Remi Forax wrote:
Hi all,
as far as i remember, the current idea to differentiate between a break label
and a break value is to let the compiler figure this out,
i wonder if it's not simpler to disallow break label (and continue label)
inside an expression switch.
After all, an expression switch do not exist yet, so no backward compatibility
issue, it may make some refactoring impossible but had the great advantage to
do not allow a lot of puzzler codes like the one below.
enum Result {
ONE, MANY
}
Result result(String[] args) {
ONE: for(String s: args) {
return switch(s) {
case "several":
case "many":
break MANY;
case "one":
break ONE;
default:
continue;
};
}
throw ...;
}
Rémi
