break seen as a C archaism
Brian Goetz
brian.goetz at oracle.com
Thu Mar 15 18:11:31 UTC 2018
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>
More information about the amber-spec-experts
mailing list