break seen as a C archaism

[Brian Goetz]

>      - That we are overloading an existing control construct, "break",
>     to mean something just different enough to be uncomfortable;
>
>
> To some degree yes, since `break <identifier>` already means something.

Digging deeper: If we spelled "break <value>" differently (yield, emit, 
defuse), would it be significantly different?  I think reusing "return" 
is worse than reusing "break", but there are other choices.  (Though 
introducing a new keyword has its own user-model challenges.)

>  Part of it is that I know how to make sense of (a) current switch and 
> (b) a simple well-behaved nice expression switch that only uses `->`, 
> but knowing that I may have to deal with (c) code that is some mixture 
> between the two feels like additional level of complexity to me. Even 
> if from an implementation standpoint it's not.

I like to think that this is pedagogical, stemming from thinking of 
switch expressions and switch statements as unrelated things.  If we 
view expression switches as a generalization of existing switch, I think 
that the dichotomy between A/B can go away.  But only if there is a 
clear enough explanation that everyone will eventually receive.

C is still an issue, and I do get the discomfort of mixing both -> and : 
cases, and I agree that good style will minimize mixing.  Outlawing 
mixing entirely isn't a great answer, though; its too common to use -> 
for all the cases except default, which often needs statements to do its 
thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/a26678cd/attachment.html>