Pretty please: Named arguments

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2069.1298937813.4748.digitalmars-d at puremagic.com...
>
> 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_.

If Phobos parameter names are that bad, then Phobos has both a code-quality 
problem and a documentation-quality problem.

> 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.
>

I don't understand why people have such a problem with changed names in an 
API. Updating calls to use a new name is fucking trivial. How many seconds 
of terrible, miserable, back-breaking work did you have to suffer through to 
update your code for the new name changes in DMD 2.052? Granted it would be 
a problem if they were constantly changing everything's name around, but 
nobody does that even for private symbols.

And if you really want to be obsessive-compulsive about it, there's always 
this:

void foo(int a) {
    alias a b;
    ...
}


> 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.

The "problem" is downright trivial, and as a library writer I'd certainly 
consider providing my users with a less error-prone API to be of benefit to 
me.


> 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.

But you no longer have to give a shit what their arbitrarily chosen order 
is. X and Y may have an obvious natural ordering, but a lot of things don't.


> 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.
>

I do _not_ want to have to read code like this:

    box(10, 15, 5, 12)

Quiz: Could you tell which of the following that is without referring to any 
docs?:
    - box(top, bottom, left, right)
    - box(top, right, bottom, left)
    - box(x, y, width, height)
    - box(x, y, rgb color, alpha)
    - box(x, y, z, hsl color)
    - box(id#, x, y, line thickness)
    - Or maybe the API author was stupid and made it something like 
box(height, x, width, y)

One could argue the code is more likely like this:

    int x = 1;
    int y = 2;
    int width = 3;
    int height = 4;
    ...
    box(x, y, width, height)

But if you look at that, do you actually *know* the API is "x, y, width, 
height"? Nope. Could be a bug staring you right in the face.

Other people have addressed the "IDE API pop-up" issue.

Additionally, I do _not_ want to have to read code like this:

    Rect rect;
    rect.top = 1;
    rect.bottom = 2;
    rect.left = 3;
    rect.right = 4;
    box(rect)

(And yes, there's "with", but IMO that makes it even worse.) And note that 
that's only 4 params, not remotely "a ton". MS has a lot of APIs like that 
and even for small structs (*especially* for small structs) it quickly makes 
the user code a mess.