# considered harmful [was C++11 lambdas]

Rémi Forax forax at univ-mlv.fr
Mon Mar 15 15:57:05 PDT 2010


Le 15/03/2010 23:27, Bob Foster a écrit :
> Harmful because it's unpleasant to look at and leads to indecipherable
> code. Every time someone proposes adding another #, the syntax gets
> uglier and less readable.
>
> I apologize for coming to this point rather late, but frankly once I
> read the # proposal and realized no one intended to implement actual
> closures, I decided the whole project was a plot to convert Java
> programmers to Scala and my mind turned to more pleasant things. This
> was a mistake, and Remi Forax's excellent counter-proposal has
> inspired me. Why _not_ try something simpler?
>    

Yes, a supporter.

> I have a (very) few nits to pick with Remi's proposal:
>
> - int(int) is a function type, not a function.
>
> - the . has no place in function call syntax; functions are not methods.
>    

It will be cool to be able to call a function only by its name
but it doesn't seem possible to twist the JLS invocation rules
to do that (see the archive of this list for more info).

> - I quite like the ( expr ) syntax when a function body is only a
> single expression, but it's not essential and if it were adopted
> should be extended to methods for consistency.
>
> - Java doesn't have type inference elsewhere, so it seems inconsistent
> to have it for functions. However, if it was going to be part of the #
> syntax, it should be allowed here, too, as Remi originally proposed,
> and extended to methods, as well.
>    

Java has type inference when resolving generic method calls and
when using the diamond operator.

> The whole proposal works syntactically because currently the
> construction Type() never appears in a valid program except after new.
> So as long as new doesn't pollute anonymous functions (a separate
> thread), function types are unambiguous to both the compiler and
> readers.
>    

[...]

Rémi


More information about the lambda-dev mailing list