return-from-lambda viewed as dangerous, good alternatives

[Mark Thornton]

Mike Swingler wrote:
> On Jan 7, 2010, at 12:45 PM, Stephen Colebourne wrote:
>
>   
>> The whole purpose of John's argument is to leave return free to be
>> used in a later JDK for non-local transfer. Lets say that is JDK 8 or
>> 9.But given the glacial speed at which many shops upgrade JDK
>> versions, this will mean that many developers will face jumping
>> straight from JDK 6 to this new JDK 8/9 with non-locals. The same
>> problems that Josh described in Devoxx thus re-appear.
>>
>> Thus I have some rules I'm following here:
>> 1) Developers must be able to trust the 'return' keyword. It must
>> never throw a NonLocalTransfer, now or in the future.
>>
>> 2) Some other element is allowed to do non-local return and throw a
>> NonLocalTransferError, eg 'throw return'.
>>
>> 3) If it looks like a method, ie. round-bracketed arguments followed
>> by code, then it must be a local return.
>>     
>
> +1
>
> In all the mainstream languages that have adopted closures, "return" really means the least surprising thing. I think non-local transfers should have a unique keyword or label syntax or whatever, and should work across traditional methods and closures when their time comes.
>
> Regards,
> ~Mike
>
>   
Surely the point of control abstraction is that return/break/continue 
look local to the containing method and that the very existence of the 
'lambda' may not be immediately apparent to casual observation. Using 
different keywords for the local transfers breaks this illusion.


Mark