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.

Reply via email to