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.


by specifying the parameter names in the signature, we don't have to specify them in the lamba creation. This doesn't replace the original way, just adds the ability to infer the names if they are not specified.

Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly.

On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
> void myfunc(double delegate(int i, int z, float f)) {....}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }


You could also write `myfunc((i,z,f) => i*z*f);` right now. The names are easy to do.

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

On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
> Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly.

This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.

On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote:
> On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
>> Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly.
>
> This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.

That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code.

- Jonathan M Davis

On Thursday, 10 September 2015 at 18:23:52 UTC, Jonathan M Davis wrote:
> On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote:
>> On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
>>> Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly.
>>
>> This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.
>
> That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code.
>
> - Jonathan M Davis

+1

On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
> by specifying the parameter names in the signature, we don't have to specify them in the lamba creation. This doesn't replace the original way, just adds the ability to infer the names if they are not specified.
>
> Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly.

How about just having numbered parameters like this:

{ $2 < ($1*$2) }

On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim Grøstad wrote:
> How about just having numbered parameters like this:
>
> { $2 < ($1*$2) }

What about this situation?

[[1, 2], [3, 4], [5, 6]].reduce!{
    auto localMax = { $1 > $2 ? $1 : $2; }
    auto first = $1.reduce!localMax;
    auto second = $2.reduce!localMax;

    return first > second ? first : second;
}

How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax?

On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote:
> On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim Grøstad wrote:
>> How about just having numbered parameters like this:
>>
>> { $2 < ($1*$2) }
>
> What about this situation?
>
> [[1, 2], [3, 4], [5, 6]].reduce!{
>     auto localMax = { $1 > $2 ? $1 : $2; }
>     auto first = $1.reduce!localMax;
>     auto second = $2.reduce!localMax;
>
>     return first > second ? first : second;
> }
>
> How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax?

Should be `return first > second ? $1 : $2`, but you get the idea.

On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim Grøstad wrote:
> How about just having numbered parameters like this:
>
> { $2 < ($1*$2) }

The string lambdas Phobos supports basically does this:

`b < a*b`

would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.