Better lambdas!!!!!!!!!!

[Pierre Krafft via Digitalmars-d]

On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
> On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli 
> wrote:
>> On 09/10/2015 10:55 AM, Prudence wrote:
>> > How bout this:
>> >
>> > void myfunc(double delegate(int i, int z, float f)) {....}
>> >
>> >
>> > myfunc((int i, int z, float f) { return i*z*f; } }
>> >
>> > vs
>> >
>> > myfunc({ return i*z*f; })   // Names of parameters are
>> inferred from
>> > signature.
>>
>> Considering other features of the language, that's pretty much 
>> impossible in D. What if there is another i in scope:
>>
>> int i;
>> myfunc({ return i*z*f; });
>>
>> Now, should it call another overload of myfunc that takes (int 
>> z, int f) because i is something else?
>>
>> Should the compiler analyze the body of the code and decide 
>> which symbols could be parameters? And then go through all 
>> overloads of myfunc? etc.?
>>
>> Ali
>
> As I said, it could throw a warning or error. It, in some 
> sense, is already a a problem with nested blocks that hide 
> outside variables, is it not?
>
> The compiler doesn't need to scan anything. It knows the which 
> parameters from the definition!
>
>
> -> void myfunc(double delegate(int i, int z, float f))  <- 
> Compiler knows to use the names here as the default names in 
> for the parameters when.
>
>
> when used:
>
> myfunc({ return i*z*f; }); <- Oh, there are the names, we know 
> what they are because the signature is tells us. The compiler 
> does the following:
>
>
> 1. Sees we have a block without any parameters defined. i.e., a 
> lambda.
>
> 2. It looks up the signature of myfunc to find out what the 
> names are
>
> 3. It sees that they are i z and f
>
> 4. Now it knows and it effectively rewrites the code as
>
> myfunc((i,z,f) { return i*z*f; });
>
> Surely this is not difficult, 4 steps?

You're making your code more brittle for a small gain. The 
suggestion makes parameter usage order important and the compiler 
can't warn about my typos.
Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return 
"y:"~y~"x:"~x;});
Or the typo in
myfunc({return i*z+f*j;});

Lambdas are already very concise. This proposal doesn't give any 
benefits outside of very simple lambdas. Such lambdas are already 
so simple that they could use some standard functions instead 
(like sum, to!T, and bind).