On 2/28/11 4:48 AM, Andrej Mitrovic wrote:
> I prefer using the equals sign:
> foo(action = "dofoo", times = 100)
>
> This is how Python does it.

I went with : because that's what's already used in static struct initializers.

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.

On 2/28/11 10:51 AM, 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.

Are you the author of every function and method you call in your code?

On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> 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. So,
> > ultimately,
> > I'm not sure that they're really all that useful. I'm sure that they'd
> > be useful
> > upon occasion, but if you actually need them, then your function is
> > taking too
> > many arguments.
> > 
> > In actuality, if I were to vote on whether named arguments should be in
> > the
> > language, I would definitely vote against it (I just plain don't want
> > the code
> > clutter, and they strike me as a crutch to avoid writing functions with
> > good
> > signatures in spite of their usefulness in some situations), but I can
> > see why
> > some people might want them.
> 
> Although I am not strongly for named arguments, I think they would be a definite improvement.
> 
> Bearophile brought up one of the strongest cases for them:
> 
> foo(int width, int height) {}
> 
> Seems simple enough, I don't see how you have "too many arguments", but the call looks like this:
> 
> foo(123, 456);
> 
> So, looking at this call, can you tell which is width and which is height?  I've seen some libs that use width and height do height first also.  I usually have to go look up the API every time I'm reading/writing one of these.
> 
> But this is perfectly clear and resists API changes/differences:
> 
> foo(width: 123, height: 456);
> 
> The cool part about this is, named arguments are not required -- you can always just not use them.  But when you do use them, the code becomes much clearer.

That does have some minimal benefit, but if you're really passing around width and height much, then I'd argue that they should be put in a struct rather than passed around bare like that, and then that fixes the issue.

- Jonathan M Davis

On 2/28/11, Bekenn <leaveme@alone.com> wrote:
> I went with : because that's what's already used in static struct initializers.
>

I even forgot about those! It's also used in static arrays and static unions.

On 2/28/11, spir <denis.spir@gmail.com> wrote:
> But this conflict already exists with the
> usage
> of ':' in dyn array notation

Wait, when is ':' used with dynamic arrays?

Steven Schveighoffer napisał:

> Although I am not strongly for named arguments, I think they would be a definite improvement.
> 
> Bearophile brought up one of the strongest cases for them:
> 
> foo(int width, int height) {}
> 
> Seems simple enough, I don't see how you have "too many arguments", but the call looks like this:
> 
> foo(123, 456);
> 
> So, looking at this call, can you tell which is width and which is height?  I've seen some libs that use width and height do height first also.  I usually have to go look up the API every time I'm reading/writing one of these.
> 
> But this is perfectly clear and resists API changes/differences:
> 
> foo(width: 123, height: 456);
> 
> The cool part about this is, named arguments are not required -- you can always just not use them.  But when you do use them, the code becomes much clearer.

The classic beneficiary of named parameters is the widely understood user interface. Presentation code (layout, formatting, graphics) is naturally awash in options and switches.

Take construction of std.format.FormatSpec as a next-door example.

-- 
Tomek

On Mon, 28 Feb 2011 14:33:55 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
>> On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>
>> 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. So,
>> > ultimately,
>> > I'm not sure that they're really all that useful. I'm sure that they'd
>> > be useful
>> > upon occasion, but if you actually need them, then your function is
>> > taking too
>> > many arguments.
>> >
>> > In actuality, if I were to vote on whether named arguments should be  
>> in
>> > the
>> > language, I would definitely vote against it (I just plain don't want
>> > the code
>> > clutter, and they strike me as a crutch to avoid writing functions  
>> with
>> > good
>> > signatures in spite of their usefulness in some situations), but I can
>> > see why
>> > some people might want them.
>>
>> Although I am not strongly for named arguments, I think they would be a
>> definite improvement.
>>
>> Bearophile brought up one of the strongest cases for them:
>>
>> foo(int width, int height) {}
>>
>> Seems simple enough, I don't see how you have "too many arguments", but
>> the call looks like this:
>>
>> foo(123, 456);
>>
>> So, looking at this call, can you tell which is width and which is
>> height?  I've seen some libs that use width and height do height first
>> also.  I usually have to go look up the API every time I'm reading/writing
>> one of these.
>>
>> But this is perfectly clear and resists API changes/differences:
>>
>> foo(width: 123, height: 456);
>>
>> The cool part about this is, named arguments are not required -- you can
>> always just not use them.  But when you do use them, the code becomes much
>> clearer.
>
> That does have some minimal benefit, but if you're really passing around width
> and height much, then I'd argue that they should be put in a struct rather than
> passed around bare like that, and then that fixes the issue.

foo(dimensions(123, 456));  // not helping

-Steve

On Mon, 28 Feb 2011 14:32:52 -0500, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 2/28/11, spir <denis.spir@gmail.com> wrote:
>> But this conflict already exists with the
>> usage
>> of ':' in dyn array notation
>
> Wait, when is ':' used with dynamic arrays?

Think he meant AA.

-Steve

On 2/28/11, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> but if you're really passing around
> width
> and height much, then I'd argue that they should be put in a struct rather
> than
> passed around bare like that, and then that fixes the issue.
>

But then you're back to square one:

void foo(Size size) { }
struct Size { int width, height; }

void main() {
    auto size = Size(10, 20);  // so what is 10 and what is 20?
    foo(size);
}