On Mar 23, 2018, at 12:58 PM, Brian Goetz <brian.go...@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.go...@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
