Treatment of nested 'break'

[Brian Goetz]

> Definitely prohibited in the current spec. But... this table?

Yep.  (Sorry for the formatting.)

>> More formally; we can construct a table whose rows are the control constructs and whose columns are the nonlocal branches, and whose entries are "handlers" for a nonlocal branch.  Each block has a parent (the immediately enclosing block.)
>>
>>              break-e   break   break-l   continue   return
>>
>> switch-e      L         X       X         X          X
>> switch-s      X         L       P         L          P
>> for           X         L       P         L          P
>> while         X         L       P         L          P
>> block         P         P       P         P          P
>> labeled       X         X L*        X          P
>> lambda        X         X       X         X L
>> method        X         X X         X          L
>>
>> The handlers mean:
>>
>> X -- not allowed
>> P -- let the parent handle it
>> L -- handle it and complete normally
>> L* -- handle it and complete normally if the labels match, otherwise P
>>
> I'm worried about those X's in the first column.

Right, now I see what you mean, and now I recall the motivation. The 
idea was that there are "breaky" and "nonbreaky" contexts, and for each 
breaky context, it supports either break-e or break-{l,nothing}.

> A simplified model which the spec suggests: there are certain constructs that introduce control flow barriers: method, constructor, initializer, lambda body, switch expression body. It's an error if a break/continue/return reaches one of those and cannot be handled. Nested within one of those, all constructs may choose to handle a break/continue/return, or (by default) propagate it outward.

Right, that's where I was going with this approach.  Certain constructs 
consume certain abrupt completions, and others are barriers to certain 
abrupt completions.  I left out try-catch but it would fit into this 
approach too, with a little more work.