On 02/28/2011 08:39 PM, Steven Schveighoffer wrote:
> 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.

You're right, Steve. Sorry, distraction...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir:

> <OT>
> By the way, I wonder why people tend to systematically add one, and only one,
> space after ':', ',', ';' and never before. D code is not english!

You want to break English and Math rules only when you have a good reason.

In Python PEP8 is quite specific:

>    - Immediately before a comma, semicolon, or colon:
>
>      Yes: if x == 4: print x, y; x, y = y, x
>      No:  if x == 4 : print x , y ; x , y = y , x


> There is no reason to write "width: 123" rather than "width:123" or "width : 123".

"width :123" breaks an English rule for no purpose, and "width:123" is less readable, because there are less spaces that help the eye tell apart the parts of the text. "width : 123" looks more acceptable when you use it as a binding symbol. In functional languages sometimes you use ":" to tie list elements, and you use it with a space on both sides.



 Rather
> the opposite, ':' expresses here a link which does not binds tightlier on left side than on right side ;-)


> Same about ';': it's a separator that has no reason to stick on left side, and not on right side!

In D the ";" is used for purposes similar to English ones, as punctuation to denote when something (like a line) ends, so sticking it to the left is the right thing to do, because both English and most D is read from left to right.

Bye,
bearophile

Steven Schveighoffer:
> But other than that, it still looks more verbose than should be necessary.

This is the real problem.

We already have named arguments in today's D. You can do some stringof magic to get the parameter names and ParameterTypeTuple to assign them.

I haven't written it, but there should be no blocker in combining these:

void foo(int width, int height);

auto args = NamedParameterTypeTuple!(foo);

args.width = 10;
args.height = 20;

foo(args);


But, that's just like the struct for length of code...


If someone wanted to write the code to add the foo(width:10, height:10), I
wouldn't likely object to it's inclusion. But, I
don't see it as a big deal.

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?


No, the called function could be from a linked library, for all we know. Reordering the evaluation of the arguments would not have any effect on the function itself.

Left-to-right evaluation at the point of call would concur with the Principle of Least Astonishment:


void fun(int foo, int bar);

int moo(); // might have side-effects!

fun(bar:moo(), foo:moo());

spir <denis.spir@gmail.com> wrote:

> Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or else use ':=' ?

:= is acceptable to me. It does not clash with anything, and clearly
shows that something is being set to something.

-- 
Simen

On 2/28/11 11:53 AM, spir wrote:
> Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or
> else use ':=' ?
>
> Denis

I think we should stick with ':' due to its existing use in static struct initializers.

Adam Ruppe <destructionator@gmail.com> wrote:

> Another alternative is to give each element their own struct...
>
> struct Width { int width; alias width this; }
>
> foo(Width(10), Height(20));

Clearly this can be done better:

struct _(string s) { int data; alias data this; }

foo(_!"width"(10), _!"height"(20));

-- 
Simen

Bekenn <leaveme@alone.com> wrote:

> On 2/28/11 11:53 AM, spir wrote:
>> Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or
>> else use ':=' ?
>>
>> Denis
>
> I think we should stick with ':' due to its existing use in static struct initializers.

Seconded.

-- 
Simen

spir wrote:
> On 02/28/2011 07:51 PM, 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.

I agree.
CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).


> ???
> 
>> 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,  [...]
> 
> Just don't use them!

You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).

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.


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);

---> 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?
And if you really want to see them all the time, why not build that feature into the IDE?
("hit ctrl-f9 to show all parameter names, hit it again to hide them").

On Monday, February 28, 2011 11:37:04 Steven Schveighoffer wrote:
> 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

Like, I said if you're passing around the width and height much (as opposed to just once), then it definitely helps. But it doesn't necessarily help at the point of construction, so if you're just passing them to one function, then you don't really benefit. Still, I don't think that an example like this one makes the feature pulls its weight.

Regardless, there are obviously a lot of people who like the idea, so if they can get Walter's support, it'll likely go in. I'd just as soon that it didn't, but it's not like it's my decision, and unless all the people who dislike it are silent or haven't read this thread, it definitely looks like the majority of folks around here are in favor of it.

- Jonathan M Davis