On 2011-12-27 23:27, Timon Gehr wrote:
> On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>
>>
>>
>> Andrei
>
> Great! =)
>
> What about making => syntax available to named functions as well?
>
> class C{
> private int x;
> int getX() => x;
> }
>
>
> void main(){
> int[] arr;
> bool isOdd(int x) => x&1;
> writeln(arr.filter!isOdd());
> }
>

I wouldn't say no to that.

-- 
/Jacob Carlborg

On 2011-12-28 13:54, bearophile wrote:
> Timon Gehr:
>
>> =>  expr
>>
>> should imo be a shorthand for
>>
>> () =>  expr.
>>
>> It saves some ((())(()))().
>
> It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea.

It can already be done with the lazy arguments.

void foo (lazy int a)
{
    auto b = a();
}

int bar ();
foo(bar());

-- 
/Jacob Carlborg

On 2011-12-28 14:18, Marco Leise wrote:
> Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
>
>> On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
>>> Wouldn't it be great if Santa were to give us named arguments this
>>> year too?
>>> :)
>>
>> Only if he hates me. But I guess that I'm in the minority around here
>> in that
>> I hate the idea of named arguments.
>>
>> - Jonathan M Davis
>
> Despite that feature being optional to use, I could understand you if
> you think it only makes sense on obscure 'true'/'false' flags and prefer
> named enums there. Then there would be two ways to do the same thing,
> which annoys language purists like me ^^.
>
> (…, overwrite = true); vs. (…, CreateMode.overwrite);
>
> But named parameters can do more, like skipping some optional parameters
> and using others.
>
> int foo(int a = 0, int b = 1, int c = 2) {}
> foo(c = 3);

That's where they are really useful. When C# got named arguments and optional arguments it became a lot easier to use COM functions:

http://msdn.microsoft.com/en-us/library/dd264739.aspx

-- 
/Jacob Carlborg

On 2011-12-28 16:14, Peter Alexander wrote:
> On 28/12/11 2:57 PM, Andrej Mitrovic wrote:
>> But I bet one day Walter& Co. will have another phone conversation
>> and then magically we'll have named arguments the next day, without
>> asking the community about how it feels about the inclusion (e.g. just
>> like D1 deprecation, this lambda syntax, and other behind-the-scenes
>> decisions between Walter and Andrei). All it will take is probably an
>> angry Redditor or maybe some coworker at Facebook that asked for the
>> feature.
>>
>> I'm just against decisions made between the two heads of state that
>> happen over night. I'd like a little more transparency from our "D
>> government", if you know what I mean. ;-)
>
> The lambda syntax was discussed at length with the community a while ago.

... and it was basically decided that it should be added to the language.

-- 
/Jacob Carlborg

Le 28/12/2011 13:54, bearophile a écrit :
> Timon Gehr:
>
>> =>  expr
>>
>> should imo be a shorthand for
>>
>> () =>  expr.
>>
>> It saves some ((())(()))().
>
> It saves few (), but zero argument lambdas aren't that common in my functional-style code, and I think it decreases syntax uniformity and code readability. So I think it's a bad idea.
>
> On the other hand I think extending the applicability of this syntax to free functions/methods (as in Scala and Ada2012) is a nice idea, to shorten tiny functions/methods, that are common enough:
>
> class C {
>       private int x;
>       int getX() =>  x;
> }
>

That would be great ! Uniformity is something we should look for.

> ------------------------
>
> Walter:
>
>> They expect to see it, or else they mark D as "not having lambdas" and "not supporting functional programming".<
>
> To me this sounds like a bit silly argument to base language design on.
>
> In my opinion the most important reason for the introduction of this anonymous function syntax is that it makes D functional-style code (and generally code that uses lot of callbacks) less noisy, so it makes it more easy to write and read.
>
> Bye,
> bearophile

Both argument are fallacy. Javascript is a successful language (even if some design decisions are arguably very bad). It use a lot of callback, and promote event drivent programming so this type of consrtruct is used everywhere. In addition, in Javascript, code source size matters.

The syntax to do such a thing is more verbose in javascript. So definitively, this is a nice syntax, but this isn't that ground breaking, and this isn't even required for people to use this type of constructs.

On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
> On 2011-12-28 13:54, bearophile wrote:
>> Timon Gehr:
>>
>>> => expr
>>>
>>> should imo be a shorthand for
>>>
>>> () => expr.
>>>
>>> It saves some ((())(()))().
>>
>> It saves few (), but zero argument lambdas aren't that common in my
>> functional-style code, and I think it decreases syntax uniformity and
>> code readability. So I think it's a bad idea.
>
> It can already be done with the lazy arguments.
>
> void foo (lazy int a)
> {
> auto b = a();
> }
>
> int bar ();
> foo(bar());
>

It is not the same thing. lazy arguments do not create a closure.

On 12/28/2011 07:15 PM, deadalnix wrote:

>
> The syntax to do such a thing is more verbose in javascript. So
> definitively, this is a nice syntax, but this isn't that ground
> breaking, and this isn't even required for people to use this type of
> constructs.

People keep complaining about the verbosity of function syntax in JavaScript. There has been several attempts to fix that. One prominent example is CoffeeScript.

On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
> I can understand how Jonathan has no problem writing verbose code, but I'd rather not have to write enums all over the place just to use a true/false flag that is obvious at the call site compared to calls like this:
> 
> showWidget(true, false);

I'm not a big fan of the enum's for true/false either. I have no problem whatsoever with the above line of code. I'd much rather have that than named arguments.

The primary reason that I really don't like named arguments is the fact that the names of the parameters become part of the API. I also don't think that they add much unless you have functions with way too many parameters, and those sorts of functions shouldn't be happening anyway. And I don't like the additional complication of the possibility of reordering functiion arguments. You should be able to look at a function and know which parameters its arguments go with purely by the order, which named arguments destroy.

But all of that has been discussed at length before. I'm completely opposed to the idea, but I seem to be in the minority (at least out of those who spoke up).

- Jonathan M Davis

On 12/28/2011 09:25 PM, Jonathan M Davis wrote:
> On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
>> I can understand how Jonathan has no problem writing verbose code, but
>> I'd rather not have to write enums all over the place just to use a
>> true/false flag that is obvious at the call site compared to calls
>> like this:
>>
>> showWidget(true, false);
>
> I'm not a big fan of the enum's for true/false either. I have no problem
> whatsoever with the above line of code. I'd much rather have that than named
> arguments.
>
> The primary reason that I really don't like named arguments is the fact that
> the names of the parameters become part of the API.

That assumes every parameter is implicitly named. If named arguments ever get into the language, then they should imho be marked as named arguments explicitly at function declaration point.

> I also don't think that they add much unless you have functions with way too many parameters, and
> those sorts of functions shouldn't be happening anyway. And I don't like the
> additional complication of the possibility of reordering functiion arguments.
> You should be able to look at a function and know which parameters its
> arguments go with purely by the order, which named arguments destroy.

Why would that be beneficial?

>
> But all of that has been discussed at length before. I'm completely opposed to
> the idea, but I seem to be in the minority (at least out of those who spoke
> up).
>
> - Jonathan M Davis

I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.

On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
> > I also don't think that they add much unless you have functions with way too many parameters, and those sorts of functions shouldn't be happening anyway. And I don't like the additional complication of the possibility of reordering functiion arguments. You should be able to look at a function and know which parameters its arguments go with purely by the order, which named arguments destroy.
> Why would that be beneficial?

I'd hate to have a function like

void func(float x, float y);

where calling it

func(1.0, 2.0);

and

func(y : 1.0, x : 2.0);

don't do the same thing. All of a sudden, I have to pay attention to what names the arguments were given. I can't just read the function call like I would now. It becomes error-prone in that regard and violates the current expectations of argument order. It will make code harder to read for minimal benefit IMHO. I do _not_ think that name arguments are an improvement.

> > But all of that has been discussed at length before. I'm completely opposed to the idea, but I seem to be in the minority (at least out of those who spoke up).
> > 
> > - Jonathan M Davis
> 
> I don't need named arguments either, but I don't think they would hurt if implemented as a purely optional feature.

Since they affect the API, they _do_ hurt. Since then any changes to parameter names break code. So, it has a definite affect on code maintainibility even if I don't use the feature myself. I also don't want to see them in code. If the example above were possible, then someone would use it in their code (even if I didn't), and I'd have to deal with all of the code readibility issues that it causes. Named arguments _would_ hurt the language even if they were purely optional.

- Jonathan M Davis