On 28/02/2011 07:03, Bekenn wrote:
>     HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null, hDestWindowOverride: null, pDirtyRegion: null);

One advantage is that it would encourage self-documenting code, partly because the meaning is clearer at the caller side, and partly because library programmers would be encouraged more to make parameter names meaningful.

It also means that you don't have to remember which order the parameters of a function go in.  Though this is only useful if you can remember what the parameters are called.  For example, string search functions vary - needle/haystack, str/substr, search/seek, for/in.  (OK, so some of these I've thought up on the spot, and for/in wouldn't work (nice as it may be) as they're keywords, but you get the idea.)

Trouble is it would create fragility, as parameter names would become a new thing that can't be changed once decided without breaking existing code.  So it would be important to get them right from the beginning, and there'll be a time when the feature has just been introduced during which library programmers are in the process of changing parameter names to something meaningful.  But one way around that would be to support parameter aliases, which would also confer a few more benefits.

Stewart.

On 2/28/11 4:50 PM, Stewart Gordon wrote:
> But one way around that would be to support
> parameter aliases, which would also confer a few more benefits.

Interesting idea.  I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?

On 2/28/11 12:38 PM, Bekenn wrote:
> On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
>> One more thing, order of evaluation should still be left-to-right, not
>> in order of arguments. This means the feature cannot be a syntactic
>> rewrite (not a big issue, but definitely something to keep in mind).
>>
>>
>> Andrei
>
> I was thinking that order of evaluation should remain lexically
> left-to-right at the point of call (that is, in the order the arguments
> are specified, with any remaining default parameters coming after); is
> there a reason that would be bad or wouldn't work?

I meant the same as you.

Andrei

On 2/28/11 6:03 PM, Jonathan M Davis wrote:
> The more I think about this, the more I'm against the idea of named arguments.

I think you have been blessed to work with only small, clean APIs. Certain domains definitely promote large argument lists. Though the designs could certainly be refactored to e.g. group parameters into separate objects, it's overkill to do that. I'm afraid sheer experience is showing that your counterarguments are not based.

Andrei

On 01/03/2011 01:29, Bekenn wrote:
> On 2/28/11 4:50 PM, Stewart Gordon wrote:
>> But one way around that would be to support
>> parameter aliases, which would also confer a few more benefits.
>
> Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give
> an example of what syntax for that might look like?

I don't know, but possibly

    void setColour(int colour alias color);

and with a possibility of deprecating old names

    int find(string haystack deprecated alias s1, string needle deprecated alias s2);

Stewart.

On 2/28/2011 8:48 PM, Andrei Alexandrescu wrote:
> On 2/28/11 6:03 PM, Jonathan M Davis wrote:
>> The more I think about this, the more I'm against the idea of named
>> arguments.
>
> I think you have been blessed to work with only small, clean APIs.
> Certain domains definitely promote large argument lists. Though the
> designs could certainly be refactored to e.g. group parameters into
> separate objects, it's overkill to do that. I'm afraid sheer experience
> is showing that your counterarguments are not based.
>
> Andrei
>

Agreed.  I don't know how many times, when designing an API, I've considered making something  configurable and instead just hard coded it to avoid bloating things with yet another regular (must be passed in-order) function argument or (if I put the options in a struct) yet another type.  Besides, using structs to hold options requires boilerplate for the user of the library.  What would you rather write?

A:

Options options;
options.someOption = someValue;
fun(mandatoryArg1, mandatoryArg2, options);

B:

fun(mandatoryArg1, mandatoryArg2, someOption = someValue);

The beauty of named arguments with defaults is that they allow you to make things configurable with as little boilerplate code as possible for the library writer and as little boilerplate as possible for the user in the case where such configurability isn't needed.

On 2/28/11 5:53 PM, Stewart Gordon wrote:
> I don't know, but possibly
>
> void setColour(int colour alias color);
>
> and with a possibility of deprecating old names
>
> int find(string haystack deprecated alias s1, string needle deprecated
> alias s2);

I think that could work; I don't mind the verbosity, given that the actual need for a parameter name alias should be exceedingly rare.

"Bekenn" <leaveme@alone.com> wrote in message news:ikgs96$9in$3@digitalmars.com...
> On 2/28/11 5:05 AM, Jacob Carlborg wrote:
>> It's possible to implement this as a library: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
>>
>> Not a complete solution but it works.
>>
>
> That has scary syntax; no thanks.

It is a pretty gnarly syntax. And it doesn't support return values, and the arg values are mixed into the wrong context. But it's a hell of a lot better than nothing: calling certain functions without using named arguments scares the shit out of me. I think I'll probably use it (or something like it) on funcs that really need it.

One thing that could help is if it was modified slightly to work like this:

----------------------
int foo(int a, int b) {...}

// We need better string-mixin syntax!!!!
auto x = mixin( namedArgs(q{ foo(a=10,b=27) }) );
// Turns into -->
auto x = foo(10,27);
----------------------

If we could ever manage to get string-producing CTFEs that are implicitly mixed-in, which we desparately need anyway, then that would be:

----------------------
auto x = namedArgs(q{ foo(a=10,b=27) });
----------------------

Which I think would be a perfectly acceptable stop-gap solution until we can get *real* named arguments.

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

On 2/28/11 7:53 PM, Stewart Gordon wrote:
> On 01/03/2011 01:29, Bekenn wrote:
>> On 2/28/11 4:50 PM, Stewart Gordon wrote:
>>> But one way around that would be to support
>>> parameter aliases, which would also confer a few more benefits.
>>
>> Interesting idea. I think this might solve Jonathan Davis's main
>> complaint; could you give
>> an example of what syntax for that might look like?
>
> I don't know, but possibly
>
> void setColour(int colour alias color);
>
> and with a possibility of deprecating old names
>
> int find(string haystack deprecated alias s1, string needle deprecated
> alias s2);
>
> Stewart.

Don't know about others, but I think this is exactly the point where my "meh" detector goes off.

Andrei