Pretty please: Named arguments

[Bekenn]

Consider the following line from a project I'm playing around with:

	HRESULT hr = m_Device.Present(null, null, null, null);

Quick: What behavior does that third argument specify?  If you said, 
"Well, /obviously/, that's a handle to an alternative destination window 
for the render operation; by passing null, you're choosing not to 
provide an alternative render target." then... well, gee, I have no 
answer to that.

With named arguments, it becomes a bit easier to understand:

	HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null, 
hDestWindowOverride: null, pDirtyRegion: null);

If I remember right, Python has this (optional) feature; I'm not aware 
of anyone ever complaining about it.  It also nicely provides a solution 
to the bool argument problem: 
http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx

But wait, there's more!

Named arguments get a +1 synergy bonus with default arguments.  When 
using parameter names to specify arguments, the order in which those 
arguments are passed no longer matters.  Imagine if the Present() method 
above provided the default argument null for each parameter:

interface IDirect3DDevice9 : IUnknown
{
	...
	HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect 
= null, HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion = 
null);
	...
}

We can do this in the D binding without running afoul of any linkage 
issues, and it simplifies the Present() call for its most common usage, 
which I think is a good thing.  Now, let's say I'm doing something 
special; suppose I'm not worried about source and destination rectangles 
or dirty regions, but I do want to supply a different render target. 
With named arguments, that's easy to do without making things messy:

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

Named arguments should also play nicely with positional arguments:

	auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);

Lastly, wouldn't be an entirely new feature; D already supports named 
arguments for static struct initializers.  I merely propose sharing the 
love with normal functions and struct literals.

Here are the rules I have in mind:

1) Named arguments are not a replacement for positional arguments. 
Arguments fall into three categories: positional, named positional, and 
named non-positional.  An argument is positional if no name is supplied. 
  An argument is named positional if a name is supplied and its position 
matches the parameter's position in the function declaration.  An 
argument is named non-positional if a name is supplied and either a) its 
position does not match the parameter's position in the function 
declaration, or b) it is immediately preceded by a named non-positional 
argument.

2) No positional argument may appear after a named non-positional argument.

3) Named non-positional arguments may appear in any order.


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?