On 10/13/14, 4:18 PM, 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?
One simple thing we did in Crystal is to allow invoking a function with
named arguments only for arguments that have a default value. For example:
void foo(int x, int y = 2, int z = 3) { ... }
foo(x, y: 10);
foo(x, y: 10, z: 20);
foo(x, z: 30)
But not this:
foo(x: 10)
The logic behind this is that named arguments are usually wanted when
you want to replace one of the default values while keeping the others'
defaults. You could specify names for arguments that don't have a
default value, but that only gives a small readability aid. Changing a
default value in the middle is a new feature.
This greatly simplifies the logic, since parameter reordering can only
happen for names that have default values and you can always fill the
gaps. Also, default values can also appear last in a function signature.
