Pretty please: Named arguments

[Bekenn]

On 2/28/11 1:38 PM, Don wrote:
> spir wrote:
>> On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
>>> I'm not entirely against named arguments being in D, however I do
>>> think that any
>>> functions that actually need them should be refactored anyway.
>
> I agree.
> CreateFont() in the Windows API, I'm looking at you. (For Linux people,
> that function has about 12 parameters).

That's a great example of where named parameters can come in very handy. 
  As a consumer of the API, you do not have the option of refactoring 
CreateFont(); you have to play the cards you're dealt.  Named arguments 
allow you to annotate in a compiler-verified fashion.

>> Just don't use them!
>
> You don't have that option. At least, if you're a library developer, you
> don't. (I'm a bit sick of people saying "you don't have to use it if you
> don't want to" in language design. If it is in the language, you don't
> have a choice. You will encounter it).

You may encounter it, but nothing says you ever have to write it.  There 
is no way to write a function such that callers would have to use named 
arguments in the function call.  (If there were, then I'd agree with you 
-- that would be bad.)

>
> There are a couple of things that I really, really don't like about the
> names argument idea:
> 1. It makes parameter names part of the API.
> Providing no way for the function writer to control whether it is part
> of the API or not, and especially, doing it retrospectively, strikes me
> as extremely rude.
>

A valid point.  I think I would already consider parameter names to be 
part of the API, though; generated documentation relies upon them, as do 
contracts.  Admittedly, this would be the first place where they leak 
directly into caller code.

> 2. It introduces a different syntax for calling a function.
> foo(4, 5);
> foo(x: 4, y: 5);
> They look different, but they do exactly the same thing. I don't like
> that redundancy.

You're right, it is redundant.  So is this:

Declaration:
	void func(int a = 0);

Use:
	func();		// ok
	func(0);	// same as above

Are you also against default arguments, then?

>
> Especially since, as far as I can tell, the named arguments are just
> comments (which the compiler can check).

Look again at my example from the first post:

	HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);

In this usage, the named argument allows me to skip over the first two 
parameters, which receive their default arguments.  This seems highly 
valuable to me.

> But I still don't see the need for this feature. Aren't people using
> IDEs where the function signature (with parameter names) pops up when
> you're entering the function, and when you move the mouse over the
> function call?

The point (in the annotation use case) is less in the writing than in 
the reading.