Pretty please: Named arguments

Nick Sabalausky a at a.a
Mon Feb 28 20:17:21 PST 2011


"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2068.1298929852.4748.digitalmars-d at puremagic.com...
> On Monday, February 28, 2011 13:38:34 Don wrote:
>>
>> 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.
>>
>> 2. It introduces a different syntax for calling a function.
>> foo(4, 5);
>> foo(x: 4, y: 5);
>> They look different, but they do exactly the same thing. I don't like
>> that redundancy.
>>

a + b
b + a
a - (-b)
b.opBinary!"+"(a);
alias a poop; alias b butt; poop + butt
(SomeType w, SomeType f) { return w - (-f); } (a, b)

And yet, rightfully, no one gives half a shit that those redundancies are 
possible.

(Oh my god, we shouldn't have unary minus, operator overloading, alias, or 
anonymous functions, because look at the possible redundancies they can 
create!!!)

>>
>> Especially since, as far as I can tell, the named arguments are just
>> comments (which the compiler can check).
>> If so, a syntax like this would be possible, with no language change at
>> all:
>>
>> pragma(namedarguments); // applies to whole module
>>
>> foo(/*x*/ 4, /*y*/ 5);

Semantically-meaningful comments? Ultra-yuck!

Plus that would seriously fuck up my habit of temporarily commenting out old 
arguments.

>>
>> ---> if a function parameter has a comment which forms a valid
>> identifier, it's a named parameter.
>>
>> But I still don't see the need for this feature. Aren't people using
>> IDEs where the function signature (with parameter names) pops up when
>> you're entering the function, and when you move the mouse over the
>> function call?

Wasn't your first objection "It makes parameter names part of the API"? 
Sounds like the same thing to me.


> However, I consider them to
> be a big _problem_, not a feature - _especially_ the ability to rearrange 
> the
> function arguments. All of a sudden you could have
>
> foo(4, 5);
> foo(x : 4, y : 5);
> foo(y : 5, X : 4);
>
> all making _exactly_ the same function call. That seem _very_ bug-prone 
> and
> confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, 
> x :
> 4)? Not good. The amount of effort to understand the code becomes 
> considerably
> higher. You could be very familiar with foo and know exactly what 
> parameters it
> takes and totally mistake what it's really getting passed, because the 
> arguments
> were flipped in comparison to the function parameters.
>

1. I don't want to try to remember the "obvious" ordering of top, bottom, 
left and right. (Note that despite how I just happened to order them there, 
CSS considers it natural to go top, right, bottom, left instead. And I can't 
disagree that that's a perfectly intuitive ordering, too).

2. You've merely given an example of misuse. Everything can be misused. So 
that's a not a valid argument against it anyway.





More information about the Digitalmars-d mailing list