On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisp...@gmx.com>
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. So,
ultimately,
I'm not sure that they're really all that useful. I'm sure that they'd
be useful
upon occasion, but if you actually need them, then your function is
taking too
many arguments.
In actuality, if I were to vote on whether named arguments should be in
the
language, I would definitely vote against it (I just plain don't want
the code
clutter, and they strike me as a crutch to avoid writing functions with
good
signatures in spite of their usefulness in some situations), but I can
see why
some people might want them.
Although I am not strongly for named arguments, I think they would be a
definite improvement.
Bearophile brought up one of the strongest cases for them:
foo(int width, int height) {}
Seems simple enough, I don't see how you have "too many arguments", but
the call looks like this:
foo(123, 456);
So, looking at this call, can you tell which is width and which is
height? I've seen some libs that use width and height do height first
also. I usually have to go look up the API every time I'm reading/writing
one of these.
But this is perfectly clear and resists API changes/differences:
foo(width: 123, height: 456);
The cool part about this is, named arguments are not required -- you can
always just not use them. But when you do use them, the code becomes much
clearer.
-Steve
