On Apr 25, 2019, at 2:11 AM, Gavin Bierman <gavin.bier...@oracle.com> wrote: > > However, now we are proposing a completely new break-with statement, perhaps > the potential for confusion is reduced? The break-with statement can only be > used to produce a value for a switch expression. So there should not be a > confusion if that switch expression contains a switch-statement or > for/while/do statement. In other words, I would like to propose that we > generalise the table to the following (changes in **-**): > > break-with break break-l continue return > switch-e H X X X X > switch-s **P** H P P P > for/while/do **P** H P H P > block P P P P P > labeled P P H* P P > lambda X X X X H > method X X X X H > > > [It is useful to compare with the column for the return statement. This can > return a value to the outer method/lambda regardless of any enclosing > switch-statement or for/while/do statements.] > > What do you think?
I think return : lambda :: break-with : switch-e. And your new table reflects that. The current design, as you say, makes breakable control flow a no-go zone for break-e, on the grounds that break-e looks too much like break. <aside> I never understood (or was happy with) this decision, because in fact break-e looks more like break-l, and break-l will very happily do its job and break out of break-able expressions. Making break-e less capable than break-l, because it could cause similar kinds of confusion as break-l, was a sad outcome for me. </aside> In any case, break-with very clearly matches only to expression switches, so it is even less ambiguous than return (which matches both lambdas and methods). Let 'er fly! — John
