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.
I think that's a reasonable conversation -- but it wouldn't make me any
more interested in softening the break-e rules. That feels like all
downside and no upside to me. And, requiring the parens may well just
be seen as fussiness on the part of the compiler, so I'm not sure of the
point.
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 don't think "expressions always complete normally or throw" is a
"problem" to be "fixed" -- I think its a feature!
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.
No, you can do this:
e-switch {
LABEL:
s-switch {
s-switch { break LABEL; }
}
}
You just can't "throw" *across* an e-switch boundary. The X means if a
nested construct doesn't handle it, there's a problem.
