return-from-lambda viewed as dangerous, good alternatives

[Stephen Colebourne]

Neal Gafter wrote:
> The transition to SE 7 is transitory, so any benefits during that
> transition are by definition of transitory value.  The language
> features introduced during that transition, however, are hopefully
> permanent, so the primary driver should be the wholistic design of the
> language after the transition.  In other words, we should minimize
> artifacts of the language that arise because the the transition
> effects.
> 
> In this particular case, I don't think it is as important to maximize
> the opportunities to unwisely refactor inner classes to closures by
> people who are unfamiliar with the new language construct as it is to
> support effective use of the language after the transition is complete
> by people who are familiar with the new language construct.

My point, and where we disagree to some degree, is that what exists 
today is the key driver, not what might be wanted in a perfect, pure 
world. (This is related to Java's don't break compatibility).

(One could for example posit that given the rise of alternate languages, 
it is possible that over 50% of the code that will ever be written in 
Java has already been written. Of course we can't prove that one way or 
another.)

I'd also say that refactoring one method inner classes to lambdas is 
where all the focus is. And yes, I know that is use case driven.

> Having said that, I believe CfJ 0.6 a&b <http://www.javac.info>
> illustrate that there is not necessarily a conflict between the two
> goals, as they can be achieved concurrently.

It is one suggestion. There are others, which I outlined.

>> I should also note that there are at least three different ways to add
>> non-local returns from a Project Lambda type solution.
> 
> You appear to be confusing the goal of transparency with elements
> required to achieve it.  Your suggestions provide constructs related
> to those elements without actually supporting transparency, and
> therefore don't meet that goal.

I didn't go into detail, because thats not the point. I hope you would 
accept that items #2 and #3 on my list (new syntax/language feature) can 
be fully transparant, as they don't exist today.

The point I'm arguing is that the lambdas as described in the straw-man, 
and as proposed for inclusion should be non-transparant. And further, 
that because they capture return, they won't ever be transparent. But 
that doesn't prevent _something_else_ being added later (completely 
separate) that does provide transparency (#2 or #3), or just the 
non-local return (#1).

Stephen