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?
