"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message
news:mailman.2068.1298929852.4748.digitalmar...@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.
