Treatment of nested 'break'

[Maurizio Cimadamore]

On 08/05/18 23:37, Dan Smith wrote:
> I think what prompted this degree of brittleness is worries about ambiguity between label breaks and value breaks. Let me suggest this disambiguation strategy instead (in the spirit of 6.5.2):
> - If an unqualified name appears immediately after a 'break' and occurs in the scope of a label with that name, it is a LabelName
> - Otherwise, it is an ExpressionName
I might be wrong, but I think the brittleness is only tangentially 
related to disambiguation of label vs. value. I believe what we also 
wanted to avoid was for a 'break expression' to appear nested inside 
another break-y context - e.g. another statement switch - example:

boolean v = switch (e1) {
     case "One":
            switch (e2) {
                   case 42: break false; // <-----
            }
            break true;
     ...
}

The fact that we can 'break false' from a switch (statement) nested 
inside a switch (expression) is visually very confusing - and I've seen 
code snippets (one of javac regression tests) where it was virtually 
impossible to determine whether a switch was an expression or a 
statement because of this fact.

So, maybe the brittleness can be tweaked, but I'd be wary of completely 
remove it.

Maurizio