break seen as a C archaism

[Maurizio Cimadamore]

So, from a language design perspective, 'return x' is wrong - but, as 
you point out, we already committed the original sin of having 'return 
== local return' for lambdas, so I'm not too convinced that we couldn't 
use the same story again here. E.g. when you say 'return', what you 
really mean is 'returning from the innermost context'. This could be a 
method (as usual), or a nested expression e.g. a lambda or a switch 
expression.

Kevin has a point in that using return is mildly worrisome when it comes 
to refactoring; but we had exactly the same problem with lambdas when we 
were considering migrating code using internal iteration (for loop) to 
code using external iteration (Stream forEach) - again, there the 
refactoring could not be 100% smooth - if the body of your loop had some 
abnormally completing branches, then there was no way to translate that 
into an external iteration idiom - at least not mechanically (e.g. 
'return x' already meant something different inside old-style for loop 
bodies).

So, seems to me that we end up with the same bag of pros and cons? E.g. 
more familiar to the user (return <expr> is something that they know and 
love), but more smelly from a design point of view (in a way that 
forecloses using 'return' to mean non-local return, but I wonder - has 
that ship already sailed?)

Maurizio



On 15/03/18 18:11, Brian Goetz 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 
>> <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/bda4b4e9/attachment.html>