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.
