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

Brian Goetz 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 
> guides.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180323/41cb3356/attachment-0001.html>

More information about the amber-spec-experts mailing list