break seen as a C archaism

[Kevin Bourrillion]

In a world where expression switch and statement switch are two very
different things, it *might* be okay to do this, but given what `return x`
does in a statement switch, this is probably a much *worse* conflict that
the conflict with `break label`.

All options are bad... except that we rescue one of them with our probable
style rule to always stick with `->` in expression switches.


On Thu, Mar 15, 2018 at 11:11 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

>
>
> 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>
> 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.)
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180315/932c20e7/attachment.html>