return-from-lambda viewed as dangerous, good alternatives

[Stephen Colebourne]

2010/1/7 Alex Buckley <Alex.Buckley at sun.com>:
> I disagree. Many Java users developing on JDK7 will not refactor existing
> code anytime soon,...

I strongly suspect that many developers/shops will refactor existing
code where possible. Continuous refactoring is considered a Good
Practice. But we can't prove this one way or another.


> 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.

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.

Point one means that return must remain totally safe. Point two allows
Project Lambda closures to be retrofitted with non-local returns (but
not transparent ones). In combination, these three points prevent
Project Lambda style closures from being used for programmer-driven
control invocation APIs. But they do not prevent a
different/semi-related language feature from offering it.

Point three also means that if a (bad) choice was made to have local
returns using something other than 'return' then I would insist that
the syntax were changed to look nothing vaguely like a method (eg.
original BGGA syntax would do)

Thus in summary, given these points and the direction of Project
Lambda's straw man, I contend that transparency wrt 'return' is an
anti-goal for statement lambdas, now and in the future.

Stephen