Disallowing break label (and continue label) inside an expression switch
Brian Goetz
brian.goetz at oracle.com
Fri Mar 23 21:42:14 UTC 2018
>
> The rest of it is about where to put the sharp edges: Can I
> break-e from a switch-e wherever I might consider doing return
> from a method/lambda? Or does break-e have extra restrictions
> to prevent certain ambiguities? Your answer is the latter.
Right. To avoid ambiguity with other breaky contexts, we let the
innermost breaky context determine the allowable break modes.
> Speaking of ambiguities, should this be illegal, even
> though under your rules it happens to be unambiguous?
> Or is it just a puzzler we tolerate?
>
> e-switch {
> LABEL:
> s-switch {
> { int LABEL = 2; break LABEL; }
> }
> }
It could be allowed (since you can't break-e from the switch), but it
seems safer to call it a compile error. After all, you can always
alpha-rename the label.
> Also the other way:
>
> LABEL:
> s-switch {
> e-switch { int LABEL = 2; break LABEL; }
> }
>
> You want "break LABEL" to be immediately recognized as
> either a break-l or a break-e. The above cases seem to
> make it hard to do so. We could declare such code
> pathological and demand a relabel in either case,
> just as we declare local variable shadowing pathological
> in most cases, demanding a renaming of one of the
> variables. Local variable shadowing is more likely
> to occur than label shadowing, given that labels
> are a rare construct, so maybe we just let the
> above be a puzzler, rather than add a rule.
Or, make it the same rule. If in "break x", x could resolve as either a
label or an expression, call it an ambiguity. (In either case,
depending on whether you rename the variable or the label, you could
then get a different error, which is "we don't serve that kind of break
round these parts.") But I think its the same game either way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180323/48bca5b8/attachment.html>
More information about the amber-spec-experts
mailing list