Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.

Here's a thread that dealt with this question:

http://forum.dlang.org/post/m1g3kb$njo$1@digitalmars.com

On Friday, 24 July 2015 at 14:34:12 UTC, Chris wrote:
> On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
>> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.
>
> Here's a thread that dealt with this question:
>
> http://forum.dlang.org/post/m1g3kb$njo$1@digitalmars.com


Okay, understood that wrong ordered named parameters might create overloading problem, but why skipping parameters is not allowed, I don't get that one though.

[code]
void test(int a=5, int b){
}

test( , 7 );
[/code]

Programmer should still be forced to provide all parameters in correct order. How would this create a problem I can't see.

On 2015-07-24 16:15, Shammah Chancellor wrote:
> Since D has optional arguments -- why don't we support named
> parameters?  There are extremely handy and work beautifully in languages
> like C#.

I think it would really good to have in D, especially since bool parameters are basically banned in favor a struct:

// banned
string toString(bool prettyPrint);
toString(false);

// preferred
string toString(PrettyPrint p);
toString(PrettyPrint.no);

// With named parameters
string toString(bool prettyPrint);
toString(prettyPrint: true);

If named parameters don't allow reordering it won't be a problem with overloading.

A simple implementation:

https://github.com/jacob-carlborg/dmd/tree/named_parameters

-- 
/Jacob Carlborg

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.

We've argued about this several times in the past. We're not adding them. They interact badly with overloading (especially if you try and add more overloads later), and they make it so that the parameter names are part of the API, which means even more bikeshedding and arguments about naming.

- Jonathan M Davis

On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
> On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
>> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.
>
> We've argued about this several times in the past. We're not adding them. They interact badly with overloading (especially if you try and add more overloads later), and they make it so that the parameter names are part of the API, which means even more bikeshedding and arguments about naming.
>
> - Jonathan M Davis

Funny, they work beautifully in C#.

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

On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
> On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
>> On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
>>> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.
>>
>> We've argued about this several times in the past. We're not adding them. They interact badly with overloading (especially if you try and add more overloads later), and they make it so that the parameter names are part of the API, which means even more bikeshedding and arguments about naming.
>>
>> - Jonathan M Davis
>
> Funny, they work beautifully in C#.
>
> https://msdn.microsoft.com/en-us/library/dd264739.aspx

Well, I don't know how C# dealt with mixing function overloading with named arguments (I haven't read the article yet), but there _are_ issues with mixing them, and Walter's sure that they interact badly enough that he's against adding named arguments to D, and if anyone wants them, they'll have to convince him otherwise.

But I for one, hope _very_ much that they never end up in either D or C++ (which are the two main languages I use). IMHO, they're hideous, and if you need them, you have too many function arguments/parameters. And I _hate_ the fact that they make it so that the function's parameters are part of the API. It just makes something else that you have to get right up front and can't change later without breaking someone's code.

But for those who really want to have them, they can always create them themselves via templates:

http://forum.dlang.org/post/hdxnptcikgojdkmldzrk@forum.dlang.org

- Jonathan M Davis

On 7/24/2015 10:15 AM, tcak wrote:
> How would this create a problem I can't see.

The question is what problem does it solve.

On 7/24/2015 1:11 PM, Jonathan M Davis wrote:
> On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
>> On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
>>> On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
>>>> Since D has optional arguments -- why don't we support named parameters?
>>>> There are extremely handy and work beautifully in languages like C#.
>>>
>>> We've argued about this several times in the past. We're not adding them.
>>> They interact badly with overloading (especially if you try and add more
>>> overloads later), and they make it so that the parameter names are part of
>>> the API, which means even more bikeshedding and arguments about naming.
>>>
>>> - Jonathan M Davis
>>
>> Funny, they work beautifully in C#.
>>
>> https://msdn.microsoft.com/en-us/library/dd264739.aspx
>
> Well, I don't know how C# dealt with mixing function overloading with named
> arguments (I haven't read the article yet)

Here's what it says:

-----------------
Use of named and optional arguments affects overload resolution in the following ways:

•A method, indexer, or constructor is a candidate for execution if each of its parameters either is optional or corresponds, by name or by position, to a single argument in the calling statement, and that argument can be converted to the type of the parameter.


•If more than one candidate is found, overload resolution rules for preferred conversions are applied to the arguments that are explicitly specified. Omitted arguments for optional parameters are ignored.


•If two candidates are judged to be equally good, preference goes to a candidate that does not have optional parameters for which arguments were omitted in the call. This is a consequence of a general preference in overload resolution for candidates that have fewer parameters.
--------------------

D already has plenty enough overloading rules, UFCS, overloading templates with non-templates, default values, constraints, overriding, covariance/contravariance, auto ref, etc., enough to thoroughly confuse everyone already :-)

On Friday, 24 July 2015 at 21:11:20 UTC, Walter Bright wrote:
> On 7/24/2015 1:11 PM, Jonathan M Davis wrote:
>> On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
>>> Funny, they work beautifully in C#.
>>>
>>> https://msdn.microsoft.com/en-us/library/dd264739.aspx
>>
>> Well, I don't know how C# dealt with mixing function overloading with named
>> arguments (I haven't read the article yet)
>
> Here's what it says:
>
> -----------------
> Use of named and optional arguments affects overload resolution in the following ways:
>
> •A method, indexer, or constructor is a candidate for execution if each of its parameters either is optional or corresponds, by name or by position, to a single argument in the calling statement, and that argument can be converted to the type of the parameter.
>
>
> •If more than one candidate is found, overload resolution rules for preferred conversions are applied to the arguments that are explicitly specified. Omitted arguments for optional parameters are ignored.
>
>
> •If two candidates are judged to be equally good, preference goes to a candidate that does not have optional parameters for which arguments were omitted in the call. This is a consequence of a general preference in overload resolution for candidates that have fewer parameters.
> --------------------
>
> D already has plenty enough overloading rules, UFCS, overloading templates with non-templates, default values, constraints, overriding, covariance/contravariance, auto ref, etc., enough to thoroughly confuse everyone already :-)

Yeah. That sounds pretty ugly. And in D, we already tend to lean towards giving an error rather than picking a better option over a worse one in order to minimize problems related to overloading. We don't need that mess to be even more complicated - especially just for syntactic sugar (though I confess, that I do think that it's syntactic salt, so I'm obviously a bit biased against it anyway).

- Jonathan M Davis