Pretty please: Named arguments

[Jonathan M Davis]

On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisProg at 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.

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.

- Jonathan M Davis