www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template default arguments

reply Bill Baxter <Bill_member pathlink.com> writes:
Howdy D folks.
I've been looking over D a bit, just reading through docs and such at this
point.   So far it looks very interesting, but I haven't had time to do any
actual programming with it yet.  Nevertheless, I haven't yet seen mention of the
two things that I would most like to see improved in C++, so I thought I would
post a couple of messages to the list to see if either this is already supported
by D, or could be supported in a future version of D.

My first C++ annoyance is template default arguments.  This is the easy one to
fix.  I once had the misfortune of having to define a non-default allocator for
all of my STL containers that would do allocation using special shared memory
alloc commands on IRIX.  It's great that STL makes it possible to do such a
thing, but it was a royal pain because the allocator is generally the very last
template argument.  So that meant everywhere I was using an STL container I had
to specify EVERY template argument, even ones where I was happy with the
default.  

For instance take the STL map:
map<Key, Data, Compare=someDefault, Alloc=someDefault>

In order to define the Alloc parameter, you have to specify the Compare
parameter too.  That's just a silly syntactical limitation with no real reason
for existing.  I should be able to specify any of the default arguments I want
and leave the others out.  

Two ways to do this I can think of are:
1) Like many scripting languages, support a keyword style syntax for default
arguments.  So I could make my map by typing 
map<MyKey, MyData, Alloc=MyAlloc>

2) Allow a special symbol to be used as an argument that just means "use the
default", like:
map<MyKey, MyData, :default:, MyAlloc>


Actually thinking about it more, the above applies to method calls really too.
I always assumed that C++'s inflexible rules for default arguments on methods
were justified because of some sort of performance concerns, but I don't see why
either of the above couldn't be handled completely at compile time for method
calls as well.  I'm no compiler writer, though.  Maybe there's something I'm
missing?  I guess C++'s crazy Koenig lookup rules make compiler writer's heads
explode quick enough as it is without throwing that into the mix.

So how about it?  Can D already do this?  Could it in the future?

Bill Baxter
May 04 2005
next sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Actually thinking about it more, the above applies to method calls  
 really too.
 I always assumed that C++'s inflexible rules for default arguments on  
 methods
 were justified because of some sort of performance concerns, but I don't  
 see why
 either of the above couldn't be handled completely at compile time for  
 method
 calls as well.


No. In "The C++ Programming Language" from Stroustrup he says that he did  
not want something like that to be possible:

someFunc(what, , , does, it, , , mean, , 2);

Ciao
uwe
May 05 2005
parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <op.sqakdrtq6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...


No. In "The C++ Programming Language" from Stroustrup he says that he did  
not want something like that to be possible:

someFunc(what, , , does, it, , , mean, , 2);


Interesting.  So you mean Stroustrup says the method calls would be hard to
understand if default arguments could specified out of order?  Unless there's
more to it than you're quoting there, that's a very weak argument.  Basically
the current default parameter syntax is equivalent to saying:

someFunc(what,are,the,rest,of,them,set,to, , , , , ,);

except it gets written as

someFunc(what,are,the,rest,of,them,set,to);

which in my opinion is harder to fully comprehend than your example, because the
person who sees the code at the bottom doesn't even have a clue that there *are*
a bunch of other hidden parameters being silently tacked on the end.  At least
the extra commas in your example clue the reader in that there *are* some
default values being used.

The thing that drives me crazy about using GUI toolkits like wxWidgets or FOX
for example, is all the default arguments I have to specify just to modify that
one I really want to set.  Here's an example widget of a constructor from FOX:

FXListBox(FXComposite *p,FXObject* tgt=NULL,FXSelector sel=0,FXuint
opts=FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,FXint x=0,FXint y=0,FXint w=0,FXint
h=0,FXint pl=DEFAULT_PAD,FXint pr=DEFAULT_PAD,FXint pt=DEFAULT_PAD,FXint
pb=DEFAULT_PAD);

Is Bjorn really going to tell me that it's better and more readable if I rummage
through the header to dig up all the default values, and type them all in:
FXListBox(p,NULL,0,FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,0,0,0,0,DEFAULT_PAD,DEFAULT_PAD,DEFAULT_PAD,DEFAULT_PAD+1);
instead of just doing this:
FXListBox(p,,,,,,,,,,,DEFAULT_PAD+1);
just so I can change the value of the last default parameter?

Personally if I have to read someone else's source code, I'd rather see the
latter code than the former.  I also don't want to have to be the one that
maintains the former and has to keep all those default parameters up to date
with the default values as they're specified in the library.

--bb
May 05 2005
next sibling parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Bill Baxter wrote:

 In article <op.sqakdrtq6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...
 
 

No. In "The C++ Programming Language" from Stroustrup he says that he did  
not want something like that to be possible:

someFunc(what, , , does, it, , , mean, , 2);


 
 
 Interesting.  So you mean Stroustrup says the method calls would be hard to
 understand if default arguments could specified out of order?  Unless there's
 more to it than you're quoting there, that's a very weak argument.  Basically
 the current default parameter syntax is equivalent to saying:
 
 someFunc(what,are,the,rest,of,them,set,to, , , , , ,);
 
 except it gets written as
 
 someFunc(what,are,the,rest,of,them,set,to);
 
 which in my opinion is harder to fully comprehend than your example, because
the
 person who sees the code at the bottom doesn't even have a clue that there
*are*
 a bunch of other hidden parameters being silently tacked on the end.  At least
 the extra commas in your example clue the reader in that there *are* some
 default values being used.
 
 The thing that drives me crazy about using GUI toolkits like wxWidgets or FOX
 for example, is all the default arguments I have to specify just to modify that
 one I really want to set.  Here's an example widget of a constructor from FOX:
 
 FXListBox(FXComposite *p,FXObject* tgt=NULL,FXSelector sel=0,FXuint
 opts=FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,FXint x=0,FXint y=0,FXint
w=0,FXint
 h=0,FXint pl=DEFAULT_PAD,FXint pr=DEFAULT_PAD,FXint pt=DEFAULT_PAD,FXint
 pb=DEFAULT_PAD);
 
 Is Bjorn really going to tell me that it's better and more readable if I
rummage
 through the header to dig up all the default values, and type them all in:
 FXListBox(p,NULL,0,FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,0,0,0,0,DEFAULT_PAD,DEFAULT_PAD,DEFAULT_PAD,DEFAULT_PAD+1);
 instead of just doing this:
 FXListBox(p,,,,,,,,,,,DEFAULT_PAD+1);
 just so I can change the value of the last default parameter?
 
 Personally if I have to read someone else's source code, I'd rather see the
 latter code than the former.  I also don't want to have to be the one that
 maintains the former and has to keep all those default parameters up to date
 with the default values as they're specified in the library.


If I were Stoustroup I would blame the designers of the library.

If you need to pass that many parameters a parameter class would 
certainly help.

I'm not sure whats better - a paramter class or named parameters.
May 06 2005
parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <427B4FA9.5000003 whisset.com>, Jan-Eric Duden says...

Bill Baxter wrote:

 
 Here's an example widget of a constructor from FOX:
 
 FXListBox(FXComposite *p,FXObject* tgt=NULL,FXSelector sel=0,FXuint
 opts=FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,FXint x=0,FXint y=0,FXint
w=0,FXint
 h=0,FXint pl=DEFAULT_PAD,FXint pr=DEFAULT_PAD,FXint pt=DEFAULT_PAD,FXint
 pb=DEFAULT_PAD);
 
 Is Bjorn really going to tell me that it's better and more readable if I
rummage
 through the header to dig up all the default values, and type them all in:
 





If I were Stoustroup I would blame the designers of the library.

If you need to pass that many parameters a parameter class would 
certainly help.

I'm not sure whats better - a paramter class or named parameters.


Yeh, I'm not particularly wild about the design of the widget constructors in
FOX either, but I understand the designer's reasoning.  It is nice in some ways
to be able to have 1 line of code <=> one widget.  That way when you go
shuffling your UI around moving a widget from here to there is just a matter of
moving one line of code.  A parameter class would require extra lines of code to
set up the parameters and just generally introduce extra superfluous classes.  

Of course in D you could use a static array initializer and still have one line
of code (or are those not implemented yet?). If the D sig was:

: FXListBox(FXComposite parent, FXListBoxOptions opts);

Then you could call it like:

: new FXListBox(parent, [pb:DEFAULT_PAD+1]);

Assuming FXListBoxOptions is a struct that has a pb member.
That's why I think Eugene's suggestion was so great.  Why bother with the struct
at all in the above example?  FXListBoxOptions is just a placeholder that
doesn't really need to be a named entity.  It serves no purpose outside of
calling this constructor, so why not just do away with it?

: new FXListBox(parent, pb:DEFAULT_PAD+1);

And use the original signature with all those default values.

It acknowledges the fact that both argument lists and structs are lists of
type-identifier pairs. (Although structs can contain other structs, whereas
argument lists can't contain argument lists.)  If you can initialize a struct
with identifier-value pairs in D, why not argument lists, too?  There is one
other small difference, in that argument list generally has some elements that
must be 'initialized' (i.e. no default value), whereas structs don't have that.


But I don't see why it couldn't work, and work just as well for template
argument lists as for method argument lists.

Does it make the compiler's job too hard to match calls with the method they
invoke when overloading is in the mix?  It does mean that these two methods
could no longer coexist:

real fun(int a=5,string b="hello");
real fun(string b="hello", int a=5);

In current C,C++,D those are different methods but a call like
fun(a:2,b:"no good") would now be ambiguous.  Although I suppose if you just
changed the argument names in the second example it wouldn't be ambiguous:

real fun(int a=5,string b="hello");
real fun(string c="hello", int d=5);

So that's only going to be a problem if you write code that has the exact same
types and argument names in different orders, which is probably something you
shouldn't be doing anyway.

One potential downside is that it would mean that the name of arguments suddenly
has significance, unlike in C where you can leave them out entirely.  That means
user code can break if a library maintainer just renames an argument.   Is this
one of those cases like the switch statement where Walter doesn't want it to
look just like C but act differently?


--bb
May 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"Bill Baxter" <Bill_member pathlink.com> wrote in message
news:d5m8a3$2mc6$1 digitaldaemon.com...

 Does it make the compiler's job too hard to match calls with the method


they

 invoke when overloading is in the mix?  It does mean that these two


methods

 could no longer coexist:

 real fun(int a=5,string b="hello");
 real fun(string b="hello", int a=5);

 In current C,C++,D those are different methods but a call like
 fun(a:2,b:"no good") would now be ambiguous.


I hadn't thought of that, but you're right. It's not an insoluble problem,
but it does make the compiler's job of disambiguating overloaded functions
significantly harder.
May 09 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Bill Baxter" <Bill_member pathlink.com> wrote in message
news:d5d3dc$12jv$1 digitaldaemon.com...

 Is Bjorn really going to tell me that it's better and more readable if I


rummage

 through the header to dig up all the default values, and type them all in:


FXListBox(p,NULL,0,FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL,0,0,0,0,DEFAULT_P
AD,DEFAULT_PAD,DEFAULT_PAD,DEFAULT_PAD+1);

 instead of just doing this:
 FXListBox(p,,,,,,,,,,,DEFAULT_PAD+1);
 just so I can change the value of the last default parameter?

 Personally if I have to read someone else's source code, I'd rather see


the

 latter code than the former.  I also don't want to have to be the one that
 maintains the former and has to keep all those default parameters up to


date

 with the default values as they're specified in the library.


I agree that stinks, but I also put the blame on the design of FXListBox. It
should provide a few overloads of that functions that minimize the number of
default parameters.
May 09 2005
prev sibling next sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
Unless I missed something in the doc, it looks like D handles default template
arguments just like C++.  I.e. you can't specify the Nth without specifying all
the ones before it too.

So c'mon people, I can't be the only one who finds having to manually specify
lots of default parameters to be irksome and a completely unnecessary practice
in the 21st century.  Can I?  Can I get at least an 'amen' from the audience?
Anyone?  Or failing that, at least a compelling argument as to why I'm an idiot.
Uwe's appeal-to-authority argument didn't really convince me.

--bb

In article <d5bt8k$3bd$1 digitaldaemon.com>, Bill Baxter says...

My first C++ annoyance is template default arguments.  This is the easy one to
fix.
May 05 2005
parent Matthias Becker <Matthias_member pathlink.com> writes:
Unless I missed something in the doc, it looks like D handles default template
arguments just like C++.  I.e. you can't specify the Nth without specifying all
the ones before it too.


Right.


So c'mon people, I can't be the only one who finds having to manually specify
lots of default parameters to be irksome and a completely unnecessary practice
in the 21st century.  Can I?


In the 21st century you just don't have things with many paramters. So you can't
have things with many default paramters.

e.g. group some of the parameters to structs and pass them.

A function like



gets



and is called like:



This way you can do things like this:









But perhaps you should rething your design in general if you have functions with
many arguments.

-- Matthias Becker
May 10 2005
prev sibling parent reply "Eugene Pelekhay" <pelekhay gmail.com> writes:
Hi
On Thu, 05 May 2005 04:35:16 +0300, Bill Baxter <Bill_member pathlink.com>  
wrote:


 Howdy D folks.
 I've been looking over D a bit, just reading through docs and such at  
 this
 point.   So far it looks very interesting, but I haven't had time to do  
 any
 actual programming with it yet.  Nevertheless, I haven't yet seen  
 mention of the
 two things that I would most like to see improved in C++, so I thought I  
 would
 post a couple of messages to the list to see if either this is already  
 supported
 by D, or could be supported in a future version of D.

 My first C++ annoyance is template default arguments.  This is the easy  
 one to
 fix.  I once had the misfortune of having to define a non-default  
 allocator for
 all of my STL containers that would do allocation using special shared  
 memory
 alloc commands on IRIX.  It's great that STL makes it possible to do  
 such a
 thing, but it was a royal pain because the allocator is generally the  
 very last
 template argument.  So that meant everywhere I was using an STL  
 container I had
 to specify EVERY template argument, even ones where I was happy with the
 default.

 For instance take the STL map:
 map<Key, Data, Compare=someDefault, Alloc=someDefault>

 In order to define the Alloc parameter, you have to specify the Compare
 parameter too.  That's just a silly syntactical limitation with no real  
 reason
 for existing.  I should be able to specify any of the default arguments  
 I want
 and leave the others out.

 Two ways to do this I can think of are:
 1) Like many scripting languages, support a keyword style syntax for  
 default
 arguments.  So I could make my map by typing
 map<MyKey, MyData, Alloc=MyAlloc>

 2) Allow a special symbol to be used as an argument that just means "use  
 the
 default", like:
 map<MyKey, MyData, :default:, MyAlloc>


I think first is more preferrable, but with some minor changes to make it
more similar to structure initialization syntax. Something like that:

: template TFoo(T1 : int, T2 : long, T3 : SomeClass ) {}
: TFoo(T2:float) foo;

: void func(int a = 0, float b = 3.14) {}
: func(b:4);


 Actually thinking about it more, the above applies to method calls  
 really too.
 I always assumed that C++'s inflexible rules for default arguments on  
 methods
 were justified because of some sort of performance concerns, but I don't  
 see why
 either of the above couldn't be handled completely at compile time for  
 method
 calls as well.  I'm no compiler writer, though.  Maybe there's something  
 I'm
 missing?  I guess C++'s crazy Koenig lookup rules make compiler writer's  
 heads
 explode quick enough as it is without throwing that into the mix.

 So how about it?  Can D already do this?  Could it in the future?

 Bill Baxter
May 06 2005
parent Bill Baxter <Bill_member pathlink.com> writes:
In article <op.sqclqqox5ljmzl thrash>, Eugene Pelekhay says...

 Two ways to do this I can think of are:
 1) Like many scripting languages, support a keyword style syntax for  
 default
 arguments.  So I could make my map by typing
 map<MyKey, MyData, Alloc=MyAlloc>


I think first is more preferrable, but with some minor changes to make it
more similar to structure initialization syntax. Something like that:

: template TFoo(T1 : int, T2 : long, T3 : SomeClass ) {}
: TFoo(T2:float) foo;

: void func(int a = 0, float b = 3.14) {}
: func(b:4);


That is interesting.  Yeh, it is very analogous to the structure initialization
situation.  There's a list of things, and you want to spefiy some but not
others.

Is that proper D syntax though?  Wouldn't it be:

: template TFoo(T1 = int, T2 = long, T3 = SomeClass ) {}
: TFoo!(T2:float) foo;

--bb
May 06 2005