Disallowing break label (and continue label) inside an expression switch

[John Rose]

On Mar 23, 2018, at 1:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> 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; }
>         }
>     }

(Looking again at the table.)  Yes, I see; the break-l has a P.  OK, I was
reading the table wrong.

> 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.

On that we all agree:  e-switch, like any other e, can complete
normally with a value, or else can complete with a throw.
It *cannot* complete with a branch to some location other
than a catch statement (which location would be defined
by a label, loop, or switch outside the switch, if it were
anywhere, but it isn't).

OK, so half of my discomfort was a temporary misunderstanding.
You can paste locally consistent control flow in and out of
switch-e's, even if the control flow uses statement labels.
Good.

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.

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; }
        }
    }

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.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180323/4d70f09b/attachment-0001.html>