Post by Walter Bright via Digitalmars-d Post by Ary Borenszweig via Digitalmars-d Post by Walter Bright via Digitalmars-d Post by "å²©å æ¾ª" via Digitalmars-d
Are there good reasons not to add something like this to the
or is it
simply a matter of doing the work? Has it been discussed
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.
int foo(ulong x);
Named parameters are often desired so that default arguments
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
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.