Pretty please: Named arguments

[Jim]

Jonathan M Davis Wrote:

> On Monday, February 28, 2011 14:25:05 Bekenn wrote:
> > On 2/28/11 1:38 PM, Don wrote:
> > > spir wrote:
> > >> On 02/28/2011 07:51 PM, Jonathan M Davis 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.
> > > 
> > > I agree.
> > > CreateFont() in the Windows API, I'm looking at you. (For Linux people,
> > > that function has about 12 parameters).
> > 
> > That's a great example of where named parameters can come in very handy.
> >   As a consumer of the API, you do not have the option of refactoring
> > CreateFont(); you have to play the cards you're dealt.  Named arguments
> > allow you to annotate in a compiler-verified fashion.
> > 
> > >> Just don't use them!
> > > 
> > > You don't have that option. At least, if you're a library developer, you
> > > don't. (I'm a bit sick of people saying "you don't have to use it if you
> > > don't want to" in language design. If it is in the language, you don't
> > > have a choice. You will encounter it).
> > 
> > You may encounter it, but nothing says you ever have to write it.  There
> > is no way to write a function such that callers would have to use named
> > arguments in the function call.  (If there were, then I'd agree with you
> > -- that would be bad.)
> > 
> > > There are a couple of things that I really, really don't like about the
> > > names argument idea:
> > > 1. It makes parameter names part of the API.
> > > Providing no way for the function writer to control whether it is part
> > > of the API or not, and especially, doing it retrospectively, strikes me
> > > as extremely rude.
> > 
> > A valid point.  I think I would already consider parameter names to be
> > part of the API, though; generated documentation relies upon them, as do
> > contracts.  Admittedly, this would be the first place where they leak
> > directly into caller code.
> 
> And that's a _big_ problem. For instance, how many parameter names in Phobos 
> were chosen with the idea that a caller would use them? _None_. And now, if 
> named arguments are added, all of a sudden, you can't rename parameters without 
> breaking code. I, for one, do not want to _increase_ the number of things that I 
> can't change in code without breaking other people's code.  And at least with 
> functions, I could rename them and leave a deprecated alias. With parameters, I 
> don't have that option. A poorly named parameter would be set in stone unless 
> the whole function were renamed or we were willing to break other people's code. 
> Named arguments _decrease_ flexibility as far as the API goes.
> 
> On top of that, we would then have to worry about having high consistency in 
> parameter names instead of just in function names. From the perspective of the 
> library writer, this causes _more_ problems at _no_ benefit. From the perspective 
> of the library user, it does provide some benefit, but I honestly do not think 
> that
> 
> func(x : 4, y : 5);
> 
> is easier to read than
> 
> func(4, 5);
> 
> Sure, you have to know what func's parameters are, but you have to know that 
> anyway. Only now, with named arguments, you have to care about what their 
> _names_ are in addition to what they're for. I do _not_ want to have to read 
> code which uses named arguments. It's just more clutter and more intellectual 
> overhead.
> 
> The sole type of case that I have seen where named arguments are of real benefit 
> is where you're dealing with horribly written functions that have a ton of 
> parameters, and I would _hope_ that that kind of nonsense would be restricted to 
> old C APIs and the like. And if you have to deal with such C APIs from D, you 
> can write a wrapper which uses a proper struct or whatnot to encapsulate that 
> mess. Such horrendous functions shouldn't be the norm at all.
> 
> As a library user, I see little benefit to named arguments and a definite problem 
> with them in terms the added code clutter and intellectual overhead. As a 
> library writer, it gives me _no_ benefit and definitely makes my life harder. 
> Parameter names have never been part of a function's signature, and I _don't_ 
> want them to start being a part of it now.
> 
> The more I think about this, the more I'm against the idea of named arguments.
> 
> - Jonathan M Davis



I think it could be a real boon for generic code:


class House(Roof = Clay, Door = Wood, Window = Glass)
{
    Roof _roof;
    Door[] _doors;
    Window[] _windows;
}

auto home = new House(Roof: Gingerbread, Window: Sugar)();



You would probably parameterize as much as possible, like the container types for _doors and _windows -- i.e. anything that isn't limited by the algorithm of your choice. Everything being optional of course, and all the work is all done at compile time.

This would give you _rich_ generic types with plain interfaces. You only specify what's important to you. How's that for a template library where every part can be shifted and replaced?