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?
