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. - Jonathan M Davis
