break seen as a C archaism
kevinb at google.com
Thu Mar 15 18:18:21 UTC 2018
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>
> 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>
> 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...
More information about the amber-spec-experts