Disallowing break label (and continue label) inside an expression switch

[John Rose]

On Mar 23, 2018, at 12:58 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> In exchange, the cost on all readers is high, because they can't be sure about what "break X" means.  Why burden all users with this complexity?  Why
> spend any of our complexity budget on such a low-leverage option? 

It seems to me that your argument cuts in a different direction:  If the
important risk is that users can't be sure what "break X" means without
a non-local scan, we should absolutely require the parentheses.

After all, an e-switch can be a large construct containing its own control
flow, and the user can run into a "break X" in the middle of a page of
code without knowing what kind of break it is.

So, we could fix the main problem by requiring "break X" to always
mean the label X and "break (x)" to always mean the value x.

i just realized that the X-heavy first column also means that I can't
make use of statement labels *anywhere inside* of e-switch, even
if I just copy-and-pasted self-contained code from elsewhere.

On Mar 23, 2018, at 12:41 PM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
> 
> I would prefer to rule it out.  We don't allow returns out of the middle of a conditional, after all.  I prefer the simplicity that "all expressions either complete normally or complete abruptly with cause exception."  If you really need this kind of control flow, where maybe you yield a value or maybe you return, use a switch statement:
> 
>     int result;
>     switch (e) {
>         case 0:
>             for (int y : someInts) {
>                 if (y < x) { result = y; break ; }
>             }
>            return 0;
>        default: return e;
>     }
>     // consume result here

In the above refactoring I *must* use label-free break to escape
from the "for" statement.  Which means I don't have access to
the normal range of Java control flow constructs inside of an
e-switch.  This is unusual:  In most ways, wherever Java allows
a single statement, it also allows a block with any variety of
nested statements.  (We pushed this pretty far in Java 1.1 with
inner classes, for example.)  The effect of your proposal here
is that e-switches can only contain a simplified sub-language
of the Java statement language.  I'll bet you view that as
a positive, since it will tend to push people away from writing
really complex stuff inside of e-switches, but I see it as
a sharp edge.  The "will it refactor" heuristic exposes it
nicely; again:  I can't freely refactor between method body
and e-switch if my method body contains labeled statements.

And this limit goes in because the poor user won't deal well
with "break E"…  I think mandating "break (e)" is a lighter
weight solution, even though it has some of the
#{ Stand Out }# smell.

— John