return-from-lambda viewed as dangerous, good alternatives

[Paul Benedict]

I definitely would not want "continue", "return", or "break" to be
redefined... hence qualify them to make obvious how the react
differently with the caller. A context-sensitive keyword, perhaps?
Maybe something akin to "lambda continue", "lambda return", "lambda
break" -- making it very visible the different behavior.

On Fri, Jan 8, 2010 at 12:18 PM, Mike Swingler <swingler at apple.com> wrote:
> On Jan 8, 2010, at 9:24 AM, Neal Gafter wrote:
>
>> On Thu, Jan 7, 2010 at 6:37 PM, Joshua Bloch <jjb at google.com> wrote:
>>
>>> I don't think anyone is trying to redefine return. In Java return has always
>>> meant "return this value (or no value)" from the invocation of this method.
>>> I think that must be true whether the method is a lambda or or an ordinary
>>> method. I just don't see a problem here.
>>>
>>> I don't think this is an implementation consideration; I think it's
>>> fundamental. We're considering adding function types to the language, which
>>> define functions (AKA methods).
>>
>> If we continue to misinform people and tell them that lambdas are
>> methods in the context of this language feature, then it is true that
>> the language should reflect that correspondence.  However, I believe
>> it will be natural for programmers to become familiar with a language
>> feature that is not grown out of this misinformation.
>
> So what's the value to the ordinary developer to understand any more than "lamba's are just methods"? I really would like to understand the kinds of design patterns that will solve common tasks that is worth the conceptual overhead and losing the common understanding of "return".
>
> ~Mike
>
>