Hello everyone.

I suggest adding a new syntax for function parameter passing. To illustrate:

void foo( int a, float b ) {
    // some code
}

void main() {
    foo( 1, 2.5f ); // classic
    foo( b : 2.5f, a : -3 ); // sort of struct initializer
}

Since named arguments can be passed in any order, they can be especially useful when a function has more than one parameter with a default value.

This concept could be applied to template instantiation as well.

-Artyom Shalkhakov

You can "sort-of" do function parameters by name by turning the function into a template, and using some typedefs.

Completely untested example:

>
> typedef int _Foo;
> _Foo Foo(int e) { return cast(_Foo) e; }
>
> typedef int _Bar;
> _Bar Bar(int e) { return cast(_Bar) e; }
>
> void test(T)(T t) {
>   static if (is(T==_Bar)) writefln("Got bar: ", t);
>   static if (is(T==_Foo)) writefln("Got foo: ", t);
> }
>
> void main() {
>   test(Foo=4); test(Bar=17);
> }
>

Multiple parameters can be handled with some templates and static ifs as well. :)
 --downs

downs wrote:
> You can "sort-of" do function parameters by name by turning the function into a template, and using some typedefs.
> 
> Completely untested example:
> 
>> typedef int _Foo;
>> _Foo Foo(int e) { return cast(_Foo) e; }
>>
>> typedef int _Bar;
>> _Bar Bar(int e) { return cast(_Bar) e; }
>>
>> void test(T)(T t) {
>>   static if (is(T==_Bar)) writefln("Got bar: ", t);
>>   static if (is(T==_Foo)) writefln("Got foo: ", t);
>> }
>>
>> void main() {
>>   test(Foo=4); test(Bar=17);
>> }
>>
> 
> Multiple parameters can be handled with some templates and static ifs as well. :)
>  --downs

Doing that for every function would be ugly & error-prone, though (even with the magic of nested templates/tuples/mixins).

Artyom Shalkhakov wrote:
> Hello everyone.
> 
> I suggest adding a new syntax for function parameter passing. To illustrate:
> 
> void foo( int a, float b ) {
>     // some code
> }
> 
> void main() {
>     foo( 1, 2.5f ); // classic
>     foo( b : 2.5f, a : -3 ); // sort of struct initializer
> }
> 
> Since named arguments can be passed in any order, they can be especially useful when a function has more than one parameter with a default value.
> 
> This concept could be applied to template instantiation as well.
> 
> -Artyom Shalkhakov

(Genuine question, not a flame):
To play devil's advocate for a moment: doesn't a long parameter list or lots of default arguments indicate a poor design?
Essentially, the name of the argument becomes part of the API. Why isn't function and object name good enough?

Named arguments are potentially a disastrous feature, if completely unrestricted. It was when COM needed to support VB's named arguments that Windows programming really nose-dived.

(OTOH: A string mixin can, given the name of a function, tell you what the names of all of it's default arguments are (as well as what their default values are).
I can in fact write a string mixin implementation of this feature; it's perfectly feasible. But is the concept actually a good idea?)

Don Clugston:
> Named arguments are potentially a disastrous feature, if completely unrestricted.

They are quite handy and useful when used wisely, but they require care, you don't have to use them too much otherwise you risk doing a mess (this is true for many things in Python. Python is supposed to be a language for almost-newbies, but it contains many things that must be used with discipline, to avoid creating a tangled mess instead of a program. In that regard I think Ruby is even worse than Python. I think Java helps you keep the program tidy and clean even if you have less self-discipline, because it has more built-in 'bondage', almost as Ada. At the moment D seems between Python and Java in that regard. Often the bigger the log10(line_count) is, the higher the discipline you need to write the program with, imposed by the language or self-imposed. D's macros will make D a more flexible too, but sharper and more dangerous too, so will need more self-discipline to use it. Something similar is true in Lisp too. Scheme has more hygenic macros to give some restraints to the semantic and decrease bugs).

Bye,
bearophile

Don Clugston Wrote:
> Artyom Shalkhakov wrote:
> > Hello everyone.
> > 
> > I suggest adding a new syntax for function parameter passing. To illustrate:
> > 
> > void foo( int a, float b ) {
> >     // some code
> > }
> > 
> > void main() {
> >     foo( 1, 2.5f ); // classic
> >     foo( b : 2.5f, a : -3 ); // sort of struct initializer
> > }
> > 
> > Since named arguments can be passed in any order, they can be especially useful when a function has more than one parameter with a default value.
> > 
> > This concept could be applied to template instantiation as well.
> > 
> > -Artyom Shalkhakov
> 
> (Genuine question, not a flame):
> To play devil's advocate for a moment: doesn't a long parameter list or lots of
> default arguments indicate a poor design?


A long list of parameter is not needed in order to have parameter passing par name useful: some compilers have added specific checks for memset (only 3 arguments) because quite a few people made an error in the order of parameters..


> Essentially, the name of the argument becomes part of the API. Why isn't function and object name good enough?


I could ask the opposite question: why should we restrict the API to the function and object name instead of using the full data that we have?
To answer your question: passing parameter by name increase the readability of the source, reduce the number of mistake when writing the code (and with a good IDE the number of character to type would be the same).


> Named arguments are potentially a disastrous feature, if completely unrestricted. It was when COM needed to support VB's named arguments that Windows programming really nose-dived.

Could you explain this point? (I know nothing about COM).

> (OTOH: A string mixin can, given the name of a function, tell you what the names of all of it's default arguments are (as well as what their default values are). I can in fact write a string mixin implementation of this feature; it's perfectly feasible. But is the concept actually a good idea?)

Note that passing parameter by name is only useful if programmers doesn't have to jump through hoops to do it, otherwise nobody will use it.

renoX

renoX wrote:
> Don Clugston Wrote:
>> Artyom Shalkhakov wrote:
>>> Hello everyone.
>>>
>>> I suggest adding a new syntax for function parameter passing. To illustrate:
>>>
>>> void foo( int a, float b ) {
>>>     // some code
>>> }
>>>
>>> void main() {
>>>     foo( 1, 2.5f ); // classic
>>>     foo( b : 2.5f, a : -3 ); // sort of struct initializer
>>> }
>>>
>>> Since named arguments can be passed in any order, they can be especially useful when a function has more than one parameter with a default value.
>>>
>>> This concept could be applied to template instantiation as well.
>>>
>>> -Artyom Shalkhakov
>> (Genuine question, not a flame):
>> To play devil's advocate for a moment: doesn't a long parameter list or lots of default arguments indicate a poor design?
> 
> 
> A long list of parameter is not needed in order to have parameter passing par name useful: some compilers have added specific checks for memset (only 3 arguments) because quite a few people made an error in the order of parameters..

> 
> 
>> Essentially, the name of the argument becomes part of the API. Why isn't function and object name good enough?
> 
> 
> I could ask the opposite question: why should we restrict the API to the function and object name instead of using the full data that we have?
Because it's simpler, and there's an enormous body of code (C, C++ for example) which demonstrates a language can get by perfectly well without it;

Is the extra cost worth the benefit?

> To answer your question: passing parameter by name increase the readability of the source, reduce the number of mistake when writing the code (and with a good IDE the number of character to type would be the same).

But it also means that if you change the name of a parameter in a library, user code will break. Certainly, you'd need some special syntax to specify which parameters are part of the API, otherwise you get horribly brittle code.
Overload lookup rules could become complicated.

>> Named arguments are potentially a disastrous feature, if completely unrestricted. It was when COM needed to support VB's named arguments that Windows programming really nose-dived.
> 
> Could you explain this point? (I know nothing about COM).

<flame>
VB allows you to call a C++ COM object by giving a list of argument names (as a text array, with whatever stupid VB formats are possible) together with the argument values as VB Variants. Languages like C++ were supposed to support any  combination the VB programmer chose to use. A massive complication of COM code, just to support sloppy practice by VB programmers, and even then it was only necessary because the VB interpreter was too lazy to put the parameters in the right order.
</flame>

Don Clugston:
> Because it's simpler, and there's an enormous body of code (C, C++ for example) which demonstrates a language can get by perfectly well without it;

I think D (and some dynamic languages too) have demonstrated that there are many things C/C++ lack! (but associative arrays and GC will go into C++0x anyway...)

Bye,
bearophile

bearophile Wrote:

> I think D (and some dynamic languages too) have demonstrated that there are many things C/C++ lack! (but associative arrays and GC will go into C++0x anyway...)
> 

GC seems to have been pushed after c++0x.

http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

bearophile Wrote:

> I think D (and some dynamic languages too) have demonstrated that there are many things C/C++ lack! (but associative arrays and GC will go into C++0x anyway...)
> 

GC seems to have been pushed after c++0x.

http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry