return-from-lambda viewed as dangerous, good alternatives

[Peter Levart]

On Thursday 07 January 2010 21:45:53 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.

You should NOT trust 'return' to return from a method without throwing an exception!!!

void tryThis() {
  try {
    ...
    // some 100 lines of code so that you don't see the top...
    ...
    return; // do you trust me?
    ...
    // some 100 lines of code so that you don't see the end...
    ...
  }
  finally { throw new RuntimeException(); }
}

> 
> 2) Some other element is allowed to do non-local return and throw a
> NonLocalTransferError, eg 'throw return'.

Why some other element? Why two ways of doing the same? Java developers know that 'return'  
attempts to terminate the method. If used correctly then it actually returns from a method.

> 
> 3) If it looks like a method, ie. round-bracketed arguments followed
> by code, then it must be a local return.

Each construct has it's own look. You can always associate a distinct mindset with each of them. 
Why are you so persistent in trying to associate lambdas with methods?
Morpheus once said to Neo: "Free your mind!"

> 
> Point one means that return must remain totally safe.

It is not, as demonstrated.

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

The question is what are we to gain with such specification? Is shorter syntax for something that 
we already have (anonymous inner implementations of SAM interfaces) enough of an excuse to waste 
a perfect syntax.

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

I think you're exaggerating. The possibility that someone would mistake lambda expression for a 
method is near zero. Lambda expressions do begin with a special character '#' that stands out. 
Methods are 2nd level constructs (if class declaration is 1st level), lambda expressions are 
expressions - they appear in places where you won't find any methods. You don't mistake nested 
blocks of for/do/while/if for methods, do you?

Regards, Peter