> On May 8, 2018, at 5:37 PM, Maurizio Cimadamore > <[email protected]> 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.
