return-from-lambda viewed as dangerous, good alternatives

[Alex Buckley]

Stephen Colebourne wrote:
> The primary set of users of Project Lambda are those moving up from
> Java 6.

Sorry, this is false. Something added to the Java programming language 
is for all users for all time, whether it's 2010 and they're moving up 
from 1.0.2, or it's 2020 and they're learning Java for the first time.

> They will know about inner classes (where return is local).

Yes. Any programmer at any time for any version of Java will learn that.

> Their primary set of refactoring on receiving JDK 7 will be conversion
> of one method inner classes to lambdas.

I disagree. Many Java users developing on JDK7 will not refactor 
existing code anytime soon, but will embrace lambdas for new code, 
typically when the new code is a client of a lambda-ified library.

> This refactoring would be broken by non-local returns.

Those doing refactoring would be confused by 'return' becoming 
non-local, yes. Josh Bloch described this thoroughly at Devoxx 2007. But 
'return' isn't going to be non-local in the JDK7 timeframe, so don't 
worry about it. John's question is whether 'return' should even stay 
*local*. If not, such that break/continue/return are all banned in a 
lambda, then refactoring is broken in another way, but I don't think 
that's a big deal because a tool could convert an existing inner class 
method (using return) to a lambda (using any of John's options). 
Refactoring is always going to be tool-supported.

Alex