Pretty please: Named arguments

[Jonathan M Davis]

On Monday, February 28, 2011 11:37:04 Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 14:33:55 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > 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.
> 
> foo(dimensions(123, 456));  // not helping

Like, I said if you're passing around the width and height much (as opposed to 
just once), then it definitely helps. But it doesn't necessarily help at the 
point of construction, so if you're just passing them to one function, then you 
don't really benefit. Still, I don't think that an example like this one makes 
the feature pulls its weight.

Regardless, there are obviously a lot of people who like the idea, so if they 
can get Walter's support, it'll likely go in. I'd just as soon that it didn't, 
but it's not like it's my decision, and unless all the people who dislike it are 
silent or haven't read this thread, it definitely looks like the majority of 
folks around here are in favor of it.

- Jonathan M Davis