Will D ever get optional named parameters?

Cliff via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 13 12:44:31 PDT 2014


On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote:
> On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
>> On 10/13/14, 5:47 AM, Walter Bright wrote:
>>> On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
>>>> Are there good reasons not to add something like this to the 
>>>> language,
>>>> or is it
>>>> simply a matter of doing the work? Has it been discussed 
>>>> much?
>>>
>>> Named parameters interact badly with overloading.
>>
>> Could you give an example?
>
> Nothing requires function overloads to use the same names in 
> the same order for parameters. "color" can be the name for 
> parameter 1 in one overload and for parameter 3 in another and 
> not be there at all for a third.
>
> Parameters need not be named in D:
>
>    int foo(long);
>    int foo(ulong x);
>
> Named parameters are often desired so that default arguments 
> need not be in order at the end:
>
>    int foo(int x = 5, int y);
>    int foo(int y, int z);
>
> To deal with all this, a number of arbitrary rules will have to 
> be created. Overloading is already fairly complex, with the 
> implemented notions of partial ordering. Even if this could all 
> be settled, is it worth it? Can anyone write a document 
> explaining this to people? Do people really want pages and 
> pages of specification for this?

The only thing I like named parameters for is to avoid the 
following

foo(5 /* count */, true /* enableSpecialFunctionality */)

I like the documentation, but comments in the middle does feel 
cumbersome.  Tooling could add that automatically of course.  The 
C# syntax is slightly better:

foo(count: 5, enableSpecialFunctionality: true)

I don't care for or need the ability to reorder parameters, nor 
do I want additional rules to remember vis-a-vis overloading and 
optional parameters.  And I don't want a trivial name change in 
parameters to break my code - functions already have complete 
signatures, enforcing names just adds one more thing which could 
break people for no real benefit.

Sometimes I think features are proposed for the language which 
more rightly belong in tooling.


More information about the Digitalmars-d mailing list