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

[Prudence via Digitalmars-d]

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?