On Monday 28 February 2011 23:24:00 Steven Wawryk wrote:
> On 01/03/11 08:08, Don wrote:
> > 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.
> 
> So, out of consistency, I suppose you must be against foreach, scope(exit) and every other kind of lowering?

Except that they actually do something different. All adding the variable names really do in this case is document the name of the variable that each argument is tied to and enforce that the names you give are valid. While it does allow for some increased flexibility in cases where a function takes multiple default arguments, for the most part it's just documentation. For the most part, it's not actually doing anything for you. It's not even syntactic sugar.

Now, obviously there are a number of people here who think that this compiler- verified documentation is worth having, but for the most part, that's all this is. It's not cutting down on boiler plate code or reducing how much you have to type to do a particular type of operation (in fact, it's increasing it). So, this is not at all comparable to foreach or scope or other features which use lowering to transform code. At most, this results in the re-ordering of arguments. It's a totally different type of feature.

Really, named arguments are compiler-enforced documentation which allow you to do a couple of things that you wouldn't be able to do normally (re-order arguments and give arguments for parameters with default arguments without giving arguments for parameters earlier in the parameter list which have default arguments). They're not really anything fancier than that. So, they're not really comparable to foreach or scope statements. In my opinion (and Don's it seems), they just don't pull their weight, unlike features such as foreach and scope statements. We appear to be outnumbered however.

- Jonathan M Davis

On Monday 28 February 2011 23:49:56 Jacob Carlborg wrote:
> On 2011-02-28 22:38, Don 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?
> > 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").
> 
> That's very true. I'm used to that with Descent. On the other hand, I don't know how many editors that support this that also supports D.

Unfortunately, D is going to have to become fairly mature before we have much in the way of really good IDE support. There _are_ options out there, but for the most part, when programming in D, I expect that the average programmer is forgoing the majority of benefits that a good IDE provides. So, while IDEs may help a great deal with certain things in the long run, I wouldn't expect many people to think that an IDE feature was a decent solution at this point (regardless of what you're talking about), since they're probably not using an IDE with such a feature at this point.

- Jonathan M Davis

On 01/03/11 18:25, Jonathan M Davis wrote:
> On Monday 28 February 2011 23:24:00 Steven Wawryk wrote:
>> On 01/03/11 08:08, Don wrote:
>>> 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.
>>
>> So, out of consistency, I suppose you must be against foreach,
>> scope(exit) and every other kind of lowering?
>
> Except that they actually do something different. All adding the variable names
> really do in this case is document the name of the variable that each argument
> is tied to and enforce that the names you give are valid. While it does allow
> for some increased flexibility in cases where a function takes multiple default
> arguments, for the most part it's just documentation. For the most part, it's
> not actually doing anything for you. It's not even syntactic sugar.
>
> Now, obviously there are a number of people here who think that this compiler-
> verified documentation is worth having, but for the most part, that's all this
> is. It's not cutting down on boiler plate code or reducing how much you have to
> type to do a particular type of operation (in fact, it's increasing it). So,
> this is not at all comparable to foreach or scope or other features which use
> lowering to transform code. At most, this results in the re-ordering of
> arguments. It's a totally different type of feature.
>
> Really, named arguments are compiler-enforced documentation which allow you to
> do a couple of things that you wouldn't be able to do normally (re-order
> arguments and give arguments for parameters with default arguments without
> giving arguments for parameters earlier in the parameter list which have default
> arguments). They're not really anything fancier than that. So, they're not
> really comparable to foreach or scope statements. In my opinion (and Don's it
> seems), they just don't pull their weight, unlike features such as foreach and
> scope statements. We appear to be outnumbered however.
>
> - Jonathan M Davis


Weight-pulling is the crux of the whole matter, and it is a highly subjective judgement.

My comment was in response to "They look different, but they do exactly the same thing. I don't like that redundancy.".  I was highlighting that redundancy like that is not in and of itself a bad thing.  D uses it extensively and, as long as it's not frivolous, it contributes a great deal to the usability of the language.

Back to the subjective judgement, it appears to me that the majority of people participating in this thread believe that the compiler-enforced documentation it provides *does* pull its weight.

bearophile wrote:
> Don:
> 
>> 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).<
> 
> If you add named arguments to D, you are free to not use them when you call Phobos functions or functions from libraries not written by you. 

>You have to see them only if you modify code written by other people that uses named arguments.

This is complete rubbish. You cannot prevent someone from relying on your argument names.
Changes to the language *always* affect everyone.

>> 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,
> 
> Probably I am don't understand something here. Function arguments need to be well chosen,

 so I don't mind them becoming part of the API.

Currently, they are documentation. Readable by a human. Making them part of the API is much more restrictive.

Essentially, my chief objection to named arguments is that they severely limit your ability to improve the documentation after the function has been written.

(In theory an annotation may be used to disallow the usage of named arguments for a specific function, but I think this is not necessary).
> 
> 
>> and especially, doing it retrospectively, strikes me
>> as extremely rude.
> 
> There is not much D2 code around, most D2 code is in the future, where this feature will hopefully be known to be present.

No, there's a huge body of existing code, most of it is in C.

>> 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.
> 
> In SPARK (Ada) they avoid that redundancy because you must use named arguments :-)
> To me they look the same, but the second also tells me what I am assigning numbers to.
> 
> 
>> 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.
> 
> The two following are the same thing:
> foo(x: 4, y: 5);
> foo(y: 5, x: 4);

Well, if you allowing changes in parameter ordering, it's a very much more complicated feature, that frankly I find very scary. It's of limited use but enormous complexity.

>> 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?
> 
> If you print code on a book or you show code on the web, etc, you don't have an IDE to help you.

You can always put comments in.

> D isn't designed to require an IDE. 

Yes, but this seems like a personal preference.

> And C# devs have added named arguments even if most C# programmers use an IDE. 
> 
> Bye,
> bearophile

Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 16:38:34 -0500, Don <nospam@nospam.com> wrote:
> 
>> spir wrote:
>>>  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).
> 
> encounter *reading* it or encounter *using it*?  You shouldn't ever have to use named parameters if you don't want to.  Just like you can specify all defaulted parameters, or specify all template args when calling templated functions.
> 
> I could live without named parameters (obviously!), but I certainly think reading a call with named parameters can be much easier with the parameter names than without, and I don't think you could ever say the opposite (that name-less parameters would be clearer).

For sure they can be clearer with nameless parameters!

printf(formatstr: "Hello World!\n");

> In essense, the parameter names are ALREADY an essential part of the API.  If we didn't name the parameters (entirely possible with .di files!), how shitty would programming be?

The names are for humans to read. They are documentation. That's a big difference.

On Tue, 2011-03-01 at 00:26 -0800, Jonathan M Davis wrote: [ . . . ]
> Unfortunately, D is going to have to become fairly mature before we have much in the way of really good IDE support. There _are_ options out there, but for the most part, when programming in D, I expect that the average programmer is forgoing the majority of benefits that a good IDE provides. So, while IDEs may help a great deal with certain things in the long run, I wouldn't expect many people to think that an IDE feature was a decent solution at this point (regardless of what you're talking about), since they're probably not using an IDE with such a feature at this point.

I wouldn't say mature, I would say has traction, or has market penetration.  Basically the language can be as mature as Fortran, but still be unused and hence have no community wishing to create tooling. There is also the question of whether to fit in with something pre-existing or create something new.  Eclipse, IntelliJ IDEA, Code::Blocks, NetBeans, Emacs, Vim?

For good or ill, the metric seems to be Eclipse support:  no Eclipse tooling means no users.  C++ has dealt with this.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 28 Feb 2011 13:50:52 -0800, Jonathan M Davis wrote:

> On Monday, February 28, 2011 13:38:34 Don wrote:
>> 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").
> 
> I agree with pretty much everything said here. However, as I understand it, named parameters (at least as they work in Python) would allow for you to reorder parameters and give values for paramters which are normally default parameters without giving values for the default paramters before them, and those changes could not be dealt with by comments. [...]

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

This thread caught my attention. As an outsider to D (tried it for some time, but
went back to C++/Java anyway), I'd argue IDE can be a huge asset when it comes to
promoting a language. Take a look at DevCpp, it is considered one of the worst
IDEs around because of lack of updates, but the mere fact that it comes packaged
with a compiler (old one) and click-to-build capability makes it very popular
even if people are aware of it's drawbacks. Visual C++ also comes packaged with a
compiler and it's dumb easy to create a new project and compile&run it.
Yes, an experienced programmer is used to configuring his compiler, setting all
the paths, even writing his own makefiles, but if you are to bring new people to
D, I'd say a packaged IDE + compiler working out-of-box would be a great feature.

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

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

On 03/01/2011 01:03 AM, Jonathan M Davis wrote:
>  From the perspective
> of the library user, it does provide some benefit, but I honestly do not think
> that
>
> func(x : 4, y : 5);
>
> is easier to read than
>
> func(4, 5);
>
> Sure, you have to know what func's parameters are, but you have to know that
> anyway. Only now, with named arguments, you have to care about what their
> _names_ are in addition to what they're for. I do _not_ want to have to read
> code which uses named arguments. It's just more clutter and more intellectual
> overhead.

Sorry no, you don't *have* to. Nothing forces you to use them.
And again named params are a help for /reading/. You & Don argue on a wrong basis, as if (1) they were forced on writing (2) they were supposed to be a feature at writing time.
Even you who don't want it would benefit from them at times: on the opposite of what you say above, named params /remove/ intellectual/memory load from programmers' minds/brains.

[It's like a fight against pocket calculators or the use of an encyclopedia to write a University thesis. (People should compute by hand and know all facts by heart.)]

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