Reinier Zwitserloot reinier at
Wed Jul 7 18:04:17 PDT 2010

Fair enough, I should stop using Neal's random vocabulary. You're indeed
entirely correct in that I was referring to allowing lambdas to be treated
as the block to a custom control construct.

It's perhaps true that a return in an Anonymous Inner Class Literal is today
rarely mistaken for a return from the containing method, but then the
boilerplate and indents surrounding such a return statement are far more
indicative of the usual marked for the nearest scope of a return statement:
A complete method signature one indent up, and an AICL constructor
invocation two indents up. This clear marker would disappear with lambdas.
Perhaps the rather unique arrow of Brian's new example syntax, or the # of
the original strawman serve as enough of a marker that one won't make the
mistake of misreading a return statement.

--Reinier Zwitserloot

On Thu, Jul 8, 2010 at 2:48 AM, Joshua Bloch <jjb at> wrote:

> Reinier,
> On Wed, Jul 7, 2010 at 5:33 PM, Reinier Zwitserloot <
> reinier at> wrote:
>> .
>> To preserve (future) transparency, yield is used instead of return.
> I believe this is an abuse of the word "transparency."  There's nothing
> transparent about making the "return" keyword do double duty to mean "long
> return."  It's a new concept, and if and when it is to be supported in Java,
> it deserves a new keyword.
>> Okay. It
>> has a secondary benefit, even, in that folks looking at java code
>> definitely
>> won't confuse an 'inner' return with an 'outer' one, as inner returns are
>> now called 'yield'.
> This makes little sense to me.  I don't think anyone would confuse a return
> from within a lambda with a "naked return."  People don't have that problem
> with nested classes today.
>> However, if future transparency is the goal...
> When you say "future transparency," I believe that what you mean is
> "allowing lambdas to be used to emulate control constructs in the future."
>  I think you should call it that.
>          Josh

More information about the lambda-dev mailing list