On Tue, 01 Mar 2011 07:26:28 -0500, Nick Sabalausky wrote:

> "Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message news:ikimed$2vba$5@digitalmars.com...
>> On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:
>>
>>> On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
>>>>> 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?
>>>
>>> You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
>>>
>>>> Dunno, vim doesn't do that for me currently.  Also, if reviewing code on github, there is no ide.
>>>
>>> Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread.
>>>
>>> I'm fed up with people opposing to features very relevant for code
>>> clarity, which they are not forced to use, and can hardly bother when
>>> reading code themselves. Is the second statement below really that
>>> hard to read?
>>> p = new Point([1,2,3], [3,2,1]);
>>> p = new Point(color:[1,2,3], pos:[3,2,1]);
>>
>> Are the following really that hard to read?
>>
>>  p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);
>>
>>  p = new Point(
>>        [1, 2, 3],    // color
>>        [3, 2, 1],    // pos
>>        );
>>
>> -Lars
> 
> class Point {
>     this(int[3] pos, int[3] color) {...}
> }
> 
> p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);
> 
> Big Fail.

Yeah, I'm aware of that.  I was merely opposing the "code clarity" argument by saying that we already have a feature for clarifying code: comments.

Note that I'm not against named parameters per se, and I understand their benefits.  I just think that, at this late point in D2's development, the cost of adding them outweighs the benefits.  I mean, have you looked at the spec for D2 lately?  It's starting to look like the OOXML spec!

-Lars

On 01.03.2011 13:20, spir wrote:
> I'm fed up with people opposing to features very relevant for code
> clarity, which they are not forced to use, and can hardly bother when
> reading code themselves. Is the second statement below really that hard
> to read?
>      p = new Point([1,2,3], [3,2,1]);
>      p = new Point(color:[1,2,3], pos:[3,2,1]);

I hate that "explicitness improves code clarity and readability" argument. It may be true in some cases but most of the time explicitness creates unnecessary redundancy that actually impairs readability. Add a couple more Point instances with explicitly specified argument names and you will have useless and annoying noise.

Named arguments are definitely useful when one needs to avoid specifying default parameter values but I still think we can live a happy life without them. At least until D3.

On 2/28/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Dunno, vim doesn't do that for me currently.
>
> -Steve
>

For C/C++, there's OmniCppComplete. It seems to do some parsing work and uses ctags. Now, I can use ctags and cscope in Vim with D, no problem there. But I haven't gotten around on getting autocompletion for D working. It might be possible to use the OmniCppComplete codebase and do a few edits here and there to make it work for D.

On 01.03.2011 15:52, Max Samukha wrote:
> On 01.03.2011 13:20, spir wrote:
>> I'm fed up with people opposing to features very relevant for code
>> clarity, which they are not forced to use, and can hardly bother when
>> reading code themselves. Is the second statement below really that hard
>> to read?
>>      p = new Point([1,2,3], [3,2,1]);
>>      p = new Point(color:[1,2,3], pos:[3,2,1]);
>
> I hate that "explicitness improves code clarity and readability" argument. It may be true in some cases but most of the time explicitness creates unnecessary redundancy that actually impairs readability. Add a couple more Point instances with explicitly specified argument names and you will have useless and annoying noise.
>
> Named arguments are definitely useful when one needs to avoid specifying default parameter values but I still think we can live a happy life without them. At least until D3.
Seconded.

-- 
Dmitry Olshansky

On 3/1/11 1:51 AM, Lars T. Kyllingstad wrote:
> I think I agree with you and Don here.  As for "skipping" default
> parameters, I suggest the following syntax:
>
>    void foo(int i, bool b = true, real r = 3.14, string s = "")
>    { ... }
>
>    foo(1, , , "Hello World!");
>
> This is a much smaller language change than named parameters.
>
> -Lars

When reading existing code, can you easily spot the difference between:
	foo(1,,, "Hello World!");
and
	foo(1,,,, "Hello World!");
?

Unlike named arguments, I'd argue this syntax makes things quite a bit /less/ readable.

On 3/1/11 4:40 AM, Lars T. Kyllingstad wrote:
> I just think that, at this late point in D2's development, the
> cost of adding them outweighs the benefits.  I mean, have you looked at
> the spec for D2 lately?  It's starting to look like the OOXML spec!

I started out a few weeks ago by reading through the entire spec as posted on the digitalmars site.  It only took a few days of off-time reading.  It's maybe a tenth the size of the C++ spec, if even that. Which is great -- I wouldn't want to needlessly bloat the spec -- but I don't think that argument carries much weight.

On 3/1/11 4:52 AM, Max Samukha wrote:
> I hate that "explicitness improves code clarity and readability"
> argument. It may be true in some cases but most of the time explicitness
> creates unnecessary redundancy that actually impairs readability.

Correct.  However, named arguments are not a "most of the time" feature.  Just look at some Python code, where named arguments have been supported for a very long time; you'll still mostly see people making calls using positional arguments, which is as it should be.  Named arguments are there for when they're helpful, and get out of the way when they're not.

On 2/28/11 9:07 PM, Nick Sabalausky wrote:
> 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)

Right, at which point you're essentially using named arguments anyway, except that here, a) it's not verified by the compiler, b) you've added stack or static variables (perhaps needlessly), and c) you're polluting the local namespace.

On 3/1/11, Bekenn <leaveme@alone.com> wrote:
>
> When reading existing code, can you easily spot the difference between:
> 	foo(1,,, "Hello World!");
> and
> 	foo(1,,,, "Hello World!");
> ?
>
> Unlike named arguments, I'd argue this syntax makes things quite a bit /less/ readable.
>

This syntax is used by Autohotkey, an automation scripting language. It's not that bad for scripting (when you have an api reference on the side). But when you're reading code you have to keep count of those commas, and that's when things get ugly.

On 2/28/11 1:38 PM, Don wrote:
> 1. It makes parameter names part of the API.

I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong.  Jacob Carlborg has pointed out his library implementation of this feature:

http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135

If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition.  In essence, parameter names are /already/ part of the API, because code can be written that depends on them.  And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names.

Like it or not, parameter names are already part of the API.  Adding named arguments as a language feature doesn't change that.