Disallowing break label (and continue label) inside an expression switch
brian.goetz at oracle.com
Fri Mar 23 19:58:03 UTC 2018
I think the burden should go the other way -- we should justify why such
flexibility is warranted, and I think this is difficult to do.
The conditions under which such control flow are useful are already
small, and further, when you might want to code like that, the
expression switch form offers relatively little benefit over expression
statements anyway (since by definition you're using a lot of
control-flow statements to make your complex control-flow decision.) In
exchange, the cost on all readers is high, because they can't be sure
about what "break X" means. Why burden all users with this complexity?
Why spend any of our complexity budget on such a low-leverage option?
On 3/23/2018 3:53 PM, John Rose wrote:
> On Mar 23, 2018, at 12:41 PM, Brian Goetz <Brian.Goetz at Oracle.COM
> <mailto:Brian.Goetz at Oracle.COM>> wrote:
>> I think so. Its not detecting the ambiguity, its that the
>> possibility of mixing control flow kinds means the poor reader has to
>> reason about all the possibilities, and not be sure what "break FOO"
>> means in a switch statement.
> A lighter fix, then, would be to require parentheses always.
> An even lighter fix would be leave that kind of clarification to style
More information about the amber-spec-observers