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
