Disallowing break label (and continue label) inside an expression switch
Brian Goetz
brian.goetz at oracle.com
Fri Mar 23 21:49:46 UTC 2018
Stepping back, I think there's two ways to look at this:
- break expression and break label are totally different statements,
that happen to be spelled similarly
- break is the same statement all around, but just as return requires
a value in a value-returning method and requires no value in a void
method, the meaning of break must agree with the innermost breaky context.
I think the latter is far easier for users to reason about, while giving
up relatively little flexibility. So doing a "break label" in an
e-switch is the same error as doing "return 3" in a void method.
On 3/23/2018 5:42 PM, Brian Goetz wrote:
>
>>
>> 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/33e2a5a8/attachment.html>
More information about the amber-spec-experts
mailing list