LJC Lambdas Hackday

[Dan Smith]

On May 29, 2012, at 6:30 AM, Richard Warburton wrote:

> 2. Some programmers appear to have basically no functional programming
> experience and were confused as to why they couldn’t assign back to
> their parameter in a map.  For example they wanted to write:
> 
> someIntegers.forEach(x -> x = x + 1)
> 
> rather than:
> 
> someIntegers.map(x -> x + 1)
> 
> I know this might sound silly to people subscribed to lambda-dev, but
> getting people out of a solely imperative mindset of one of the
> adoption challenges that is faced by this JSR.  If I may be so bold as
> to make a suggestion in order to help people in the right direction:
> lambda arguments being default final.  (Or maybe even always final)

Just realized today that, if your example is accurate, this should be a compiler error anyway.  So maybe this is just a matter of improving the error message?

The type expected by 'forEach' is a functional interface with a 'void' return which, per the current EDR spec, cannot be compatible with an expression lambda.

When I test it, I get an error message that says "incompatible return type int in lambda expression".

(By the way, the next EDR will include support for void methods as expression bodies; but it still will treat assignments as illegal with 'void'-return interfaces, since assignments are value-producing expressions.  There has also been some discussion about allowing an arbitrary statement expression to be compatible with a 'void' return, and in that case your example would have the behavior I thought it had originally -- compiling without error and executing as an effective no-op.)

—Dan