Treatment of nested 'break'

[Dan Smith]

I am concerned about the treatment of 'break' statements in switch expressions. The following seems like something that would be very natural to do:

boolean x = switch (expr()) {
    case FOO -> {
        for (String s : strings) {
            if (s.isEmpty()) break false;
        }
        break true;
    }
    case BAR -> true;
    default -> false;
};

This is specified as a compiler error, even though the intent is clear, and we allow code of this shape in other contexts (compare, e.g., a method body).

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

(In practice, I expect it to be rare for a real ambiguity to exist between a label name and a variable name.)

With that disambiguation rule in place, we can then treat value breaks much like label breaks:

"If no switch expression in the immediately enclosing method, constructor, initializer, or lambda body contains the break statement, a compile-time error occurs."

(No special rule about appearing inside a 'while', 'for', etc.)