Closures for Java (0.6) specification part b
Jonathan.Gibbons at Sun.COM
Mon Dec 14 21:52:58 PST 2009
Neal Gafter wrote:
> On Mon, Dec 14, 2009 at 11:47 AM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
> Ouch. That's pretty subtle, especially as the statement in a
> control invocation form is defined to use an expression lambda
> instead of a statement lambda.
> Maybe subtle for the specification, but not subtle for the Java
> programmer, as you don't see a lambda when you're writing a control
There is still potential confusion for the programmer using lambda
Someone reading 0.6a might reasonably infer that an expression lambda
could easily be converted to statement lambda by adding a "return" and
changes parens to curlies. If 0.6a were all there was, that would
work. But in 0.6b, you've added block expressions. They look great - I
want to use them - but they've broken that "obvious" rule relating
expression lambdas to statement lambdas. Suddenly, there is a
substantial non-obvious difference between expression lambdas and
With the for loop invocation syntax, we get to add another modifier to
the signature, which makes it very clear this is a different sort of
function type. Is there any similar way we could mark the type of any
function type that is to be used for control flow abstraction, not just
for loops? This would then avoid the need for the subtle semantic
difference between expression lambdas and statement lambdas, and avoid
the downstream puzzlers comparing the behavior of the two.
P.S. It wouldn't be quite so bad if the difference were the other way
around, with local return, no break/continue in expression lambdas, and
non-local return in statement lambdas, but it would still be even better
if we could make the difference more explicit, somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the closures-dev