Disallowing break label (and continue label) inside an expression switch

[Brian Goetz]

> It seems to me that your argument cuts in a different direction:  If the
> important risk is that users can't be sure what "break X" means without
> a non-local scan, we should absolutely require the parentheses.

I think that's a reasonable conversation -- but it wouldn't make me any 
more interested in softening the break-e rules.  That feels like all 
downside and no upside to me.   And, requiring the parens may well just 
be seen as fussiness on the part of the compiler, so I'm not sure of the 
point.

> So, we could fix the main problem by requiring "break X" to always
> mean the label X and "break (x)" to always mean the value x.

I don't think "expressions always complete normally or throw" is a 
"problem" to be "fixed" -- I think its a feature!

> i just realized that the X-heavy first column also means that I can't
> make use of statement labels *anywhere inside* of e-switch, even
> if I just copy-and-pasted self-contained code from elsewhere.

No, you can do this:

     e-switch {
         LABEL:
         s-switch {
             s-switch { break LABEL; }
         }
     }

You just can't "throw" *across* an e-switch boundary.  The X means if a 
nested construct doesn't handle it, there's a problem.