Pretty please: Named arguments

[Michel Fortin]

On 2011-02-28 02:03:46 -0500, Bekenn <leaveme at alone.com> said:

> Potential problems:  The only problems I can foresee here are 
> variations on the situation when there are two (or more) versions of a 
> function with the same number, type, and names of parameters, but in 
> non-matching order, like this:
> 
> void func(int a, char b);
> void func(char b, int a);
> 
> In such a case, the compiler should diagnose an error if named 
> arguments are employed.
> 
> Thoughts?

Another problem is what happens if you override a function by using 
different parameter names. For instance:

	class A {
		void func(int foo);
	}
	class B : A {
		void func(int bar);
	}

Currently, the above is allowed. Would it now become an error?

I think it'd be much easier to support named arguments if we didn't 
allow reordering. I know I'm stripping the proposal from one of its 
main benefits, but I think the essence remains. This would make the 
rather common pattern of adding a comment for each argument 
compiler-verifiable without disrupting things too much:

	draw(null, // text
	     null, // font
	     12, // size
	     0, // flags
	     );

	draw(text: null,
	     font: null,
	     size: 12,
	     flags: 0);

It would be implemented as a check for equality of the argument names 
after overload resolution. No ABI change, no interaction with 
overloading, just an extra check that if an argument name is specified 
it must match the one in the declaration.

There'd still be a funny interaction with overriding (see my first 
example), but you can always leave your argument unnamed if the 
definition keep changing the name in unpredictable ways.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/