Treatment of nested 'break'

[Dan Smith]

> On May 8, 2018, at 5:37 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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.

There's some work to be done to develop a new intuition, but I think once we've gotten there, things like this will not be so confusing.

The intuition is based on recognizing "subexpression markers"—things like "= switch" or "foo(switch". When I encounter a value break, I look for the first enclosing subexpression marker, and that's where the value goes.

My gut feeling is that, once these constructs have been socialized, people will get it.