On Mon, 28 Feb 2011 14:33:55 -0500, Jonathan M Davis <[email protected]>
wrote:
On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis
<[email protected]>
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.
That does have some minimal benefit, but if you're really passing around
width
and height much, then I'd argue that they should be put in a struct
rather than
passed around bare like that, and then that fixes the issue.
foo(dimensions(123, 456)); // not helping
-Steve
