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