Treatment of nested 'break'

Dan Smith daniel.smith at
Wed May 9 18:23:59 UTC 2018

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

More information about the amber-spec-experts mailing list