Revised semantics for break within switch expression
john.r.rose at oracle.com
Fri Apr 26 00:51:43 UTC 2019
On Apr 25, 2019, at 2:11 AM, Gavin Bierman <gavin.bierman at 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.
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.
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!
More information about the amber-spec-observers