On 02/28/2011 08:03 AM, Bekenn wrote:
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?
I'm all for a feature of named arguments. I consider it a _base_ feature D is
sadly lacking for the moment. Unlike tons of other issues, it is not a rare,
weird, or sophisticated request. Thus, it should have the highest priority once
64-bit support has reached a workable state. There does not seem to be any
feature requests for this on the issue tracker.
On the other hand, this feature may be very simple and still handy: either all
args are named, or none. E basta!
Denis
--
_________________
vita es estrany
spir.wikidot.com
