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