Disallowing break label (and continue label) inside an expression switch
Brian Goetz
brian.goetz at oracle.com
Fri Mar 2 16:12:16 UTC 2018
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
More information about the amber-spec-experts
mailing list