A nice way to step into 2012

[Jonathan M Davis]

On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
> > 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. And I don't like the additional complication of the
> > possibility of reordering functiion arguments. You should be able to
> > look at a function and know which parameters its arguments go with
> > purely by the order, which named arguments destroy.
> Why would that be beneficial?

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.

> > But all of that has been discussed at length before. I'm completely
> > opposed to the idea, but I seem to be in the minority (at least out of
> > those who spoke up).
> > 
> > - Jonathan M Davis
> 
> I don't need named arguments either, but I don't think they would hurt
> if implemented as a purely optional feature.

Since they affect the API, they _do_ hurt. Since then any changes to parameter 
names break code. So, it has a definite affect on code maintainibility even if I 
don't use the feature myself. I also don't want to see them in code. 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.

- Jonathan M Davis