A nice way to step into 2012

[bearophile]

Jonathan M Davis:

> The primary reason that I really don't like named arguments is the fact that
> the names of the parameters become part of the API.

Sometimes I don't mind to make the names part of the API.
And as you remember we have suggested an idea adapted from Scala.


void foo(int x) {}
void main() {
    foo(x: 5);
}


A deprecated() gives some transition time to change the API:

void foo(int xx deprecated(x)) {}
void main() {
    foo(x: 5); // deprecated 'x' warning
    foo(xx: 5);
}


> I also don't think that
> they add much unless you have functions with way too many parameters, and
> those sorts of functions shouldn't be happening anyway.

I'd like to use names even for functions with 3 arguments.
And named arguments offer you more flexibility in using functions. As example look at Python built-in sorted (that performs a schwartz sort on a copy of the input sequence), that has two optional arguments, using them with their name is the idiomatic way in Python because you are able to use only one of them at a time:


>>> a = [1, 5, -3, 9, -2]
>>> sorted(a)
[-3, -2, 1, 5, 9]
>>> sorted(a, key=abs)
[1, -2, -3, 5, 9]
>>> sorted(a, reverse=True)
[9, 5, 1, -2, -3]

-------------------------

> I'd hate to have a function like
> 
> void func(float x, float y);
> 
> where calling it
> 
> func(1.0, 2.0);
> 
> and
> 
> func(y : 1.0, x : 2.0);
> 
> don't do the same thing. All of a sudden, I have to pay attention to what
> names the arguments were given. I can't just read the function call like I
> would now. It becomes error-prone in that regard and violates the current
> expectations of argument order. It will make code harder to read for minimal
> benefit IMHO. I do _not_ think that name arguments are an improvement.

Expectations change and adapt to the language and you will read the function calls in a different way, taking a look at the argument order too. In many cases names are not present at the call point, so you don't need to take care of this. If the names are present at the call point you take a look at the order. The name of the arguments keep the code readable.

Regarding the "error-prone" nature of named arguments, I think you are wrong, in Ada named arguments are regarded as means to reduce possible bugs, because they avoid you to assign arguments "blindly" as now. In Python I like to know what argument I am assigning an argument to, this avoids some mistakes at the call point.

  
> If the
> example above were possible, then someone would use it in their code (even if
> I didn't), and I'd have to deal with all of the code readibility issues that
> it causes. Named arguments _would_ hurt the language even if they were purely
> optional.

Right, if language features like this are present they can't be really "optional", you find them in code written by other people.

But named argument make code _more_ readable, because they tell you what arguments you are assigning to.

Bye,
bearophile