break seen as a C archaism

[Brian Goetz]

On 3/14/2018 2:04 PM, Kevin Bourrillion wrote:
> On Wed, Mar 14, 2018 at 8:14 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     In the meantime, let me probe for what's really uncomfortable
>     about the current design point.  Is it:
>
>
>      - 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.

We had rejected this earlier for fairly obvious reasons, but let me ask 
to get a subjective response: would using "return x" be better? On the 
one hand, it's not really a return, and it doesn't build on the user 
intuition about the control flow aspects of break, but on the other, the 
return statement is already prepared to take a value, so its not adding 
a "new form" to the existing statement, though it is adding a new and 
different context.  (We abuse it slightly in lambdas, but people seem OK 
with this, probably because they think of lambdas as methods anyway.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180315/100bbf6f/attachment.html>