I tried to port some C++ code to D, and did all kinds of little tests. Then I ran into this problem:

Does D have function overloading? And if it doesn't and won't, then why is this?

I'm not sure if the term is correct, but the thing I mean is, can I do this:

int somefunc(int a, bool is_it_so = true );

or

int longfunc(int a, char[] name = "untitled", int nro = 5, bool no_no = false );

and use them e.g.

somefunc(5);

longfunc(10, "justaname");

You propably know what I mean....

?

satelliittipupu wrote:

>I tried to port some C++ code to D, and did all kinds of little tests.
>Then I ran into this problem:
>
>Does D have function overloading? And if it doesn't and won't, then why is this?
>
>I'm not sure if the term is correct, but the thing I mean is,
>can I do this:
>
>int somefunc(int a, bool is_it_so = true );
>
>or
>
>int longfunc(int a, char[] name = "untitled", int nro = 5, bool no_no = false );
>
>and use them e.g.
>
>somefunc(5);
>
>longfunc(10, "justaname");
>
>You propably know what I mean....
>
>?
>
>
>  
>
Yes I understand. D has function overloading but not optional parameters (I wish it did).

ie - the same thing can be done like:

int somefunc(int a, bool is_it_so) {}

int somefunc(int a) {somefunc(a, true);}

somefunc(5);

PS - Sorry for sending to your home address, clicked the wrong button.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Yes I understand. D has function overloading but not optional parameters (I wish it did).
[...]

Why do you want optional parameters, I prefer the phrase "default valued parameters", to be restricted to basic types?

And why should default valued parametsr be restricted to occur at the end of a formal parameter list?

So long!

Manfred Nowak wrote:

> J Anderson wrote:
>
>  
>
>> Yes I understand. D has function overloading but not optional parameters (I wish it did).
>>   
>
> [...]
>
> Why do you want optional parameters, I prefer the phrase "default valued
> parameters", to be restricted to basic types?
>  
>
Sorry I don't quite understand (are you saying there is a difference between optional and default?)
Because it's so much easier to:
1) type
2) interpret from the users perspective.

I'd rather if you could make any value optional no matter where it is in the list.

void foo(int a = 10, int b)

foo(, 10);

> And why should default valued parametsr be restricted to occur at the end
> of a formal parameter list?
>  
>
It could cause overloading problems but I still would like this.

> So long!
>  
>
-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

>Sorry I don't quite understand (are you saying there is a difference
>between optional and default?)

Yes. Consider this overloads for `action':

   void action( time t){ /* create a human beeing at time t */ }
   void action()       { /* destroy earth immediately */}

The parameter `t' is clearly optional, but not default valued.


>Because it's so much easier to:
>1) type

Easier typing means loss of redundancy. Can you justify that time improvement one can achieve by easier typing is not lost during the lifetime of the source because of more necessary reading the source over and over again to understand its meaning and finding the subtle errors that were introduced because of the lack of redundancy?


>2) interpret from the users perspective.

Are you sure? Consider a function `f' with 9 parameters `p1', `p2', ..., `p9'. Imagine, that there are three types of calls, because other than the default values have to be used:

    f( p1, p2,           p5,          p8)
    f(     p2        p4,      p6,         p9)
    f(          p3,      p5,      p7,     p9)

As you can see every parameter has to be made optional, because for every parameter exists a call for which that parameter is not needed. Now please explain why it is easier for a user, whatever that is, to interpret this three types of calls out of the 512 possible calls, that are introduced by making nine parameters optional instead of providing three types of calls.

As far as you have managed that please explain why your arguments also hold, when applied to far more complex cases, than that which I am able to present to you within limited time and space.


>I'd rather if you could make any value optional no matter where it is in
>the list.
>void foo(int a = 10, int b)
>foo(, 10);

Maybe that for such simple cases the multiargument extension, which I just suggested, will be helpfull for the one that writes the call. Under my suggested multiargument extension this call would be written:

foo( ; 10);

Incredible more complex :-)


>It could cause overloading problems but I still would like this.

Until that case, in which you were unable to detect why the compiler refuses to compile your code.

Note: you did not explain, why default valued parameters should be restricted to basic types. Is there a reason to refuse a default value for a function or delegate variable?

So long!

Manfred Nowak wrote:

>J Anderson wrote:
>
>  
>
>>Sorry I don't quite understand (are you saying there is a difference
>>between optional and default?)
>>    
>>
>
>Yes. Consider this overloads for `action':
>
>   void action( time t){ /* create a human beeing at time t */ }
>   void action()       { /* destroy earth immediately */}
>
>The parameter `t' is clearly optional, but not default valued.
>
>
>  
>
>>Because it's so much easier to:
>>1) type
>>    
>>
>
>Easier typing means loss of redundancy. Can you justify that time
>improvement one can achieve by easier typing is not lost during the
>lifetime of the source because of more necessary reading the source over
>and over again to understand its meaning and finding the subtle errors
>that were introduced because of the lack of redundancy?
>  
>
To me:

void func(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5) {}

is much easier (and less error prone) then:

void func() {func();}
void func(int a) {func(a,2);}
void func(int a, int b) {func(a,b,3);}
void func(int a, int b, int c) {func(a,b,c,4);}
void func(int a, int b, int c, int d) {func(a,b,c,d,5);}
void func(int a, int b, int c, int d, int e) {}


>>2) interpret from the users perspective.
>>    
>>
>
>Are you sure? Consider a function `f' with 9 parameters `p1', `p2', ...,
>`p9'. Imagine, that there are three types of calls, because other than the
>default values have to be used:
>
>    f( p1, p2,           p5,          p8)
>    f(     p2        p4,      p6,         p9)
>    f(          p3,      p5,      p7,     p9)
>
>As you can see every parameter has to be made optional, because for every
>parameter exists a call for which that parameter is not needed. Now
>please explain why it is easier for a user, whatever that is, to interpret
>this three types of calls out of the 512 possible calls, that are
>introduced by making nine parameters optional instead of providing three
>types of calls.
>  
>
By user, I mean the person using the class.  Remembering 9 parameters is much worse then only needing to remember 4 or less.  IMHO having more available ways of using a function is like being about to write an equation in different ways. ie

a * b + c // is basicly the same as
c + a * b
Why should be limit the way functions can be called?   In your example case it is a design issue not a language issue.

Another advantage of optional parameters is that they help force the different calls to behave the same way.

>As far as you have managed that please explain why your arguments also
>hold, when applied to far more complex cases, than that which I am able to
>present to you within limited time and space.
>  
>
In the simple example I showed before, you only need to look at one line and know how to use it.  You also only need to look at one bit of documentation.  You don't need to look though pages of code to find out if a particular overload is provided.

>>I'd rather if you could make any value optional no matter where it is in
>>the list.
>>void foo(int a = 10, int b)
>>foo(, 10);
>>    
>>
>
>Maybe that for such simple cases the multiargument extension, which I just
>suggested, will be helpfull for the one that writes the call. Under my
>suggested multiargument extension this call would be written:
>
>foo( ; 10);
>
>Incredible more complex :-)
>
>  
>
That would be ok also except is this runtime?  On one hand you don't want optional parameters but then you want the ultimate dynamic optional parameters?

>>It could cause overloading problems but I still would like this.
>>    
>>
>
>Until that case, in which you were unable to detect why the compiler
>refuses to compile your code.
>  
>
Again a design issue.

>Note: you did not explain, why default valued parameters should be
>restricted to basic types. Is there a reason to refuse a default value for
>a function or delegate variable?
>  
>
Did I say that?  If I have it would have only been to make the job easier on Walter however optional everything I say.

>So long!
>  
>

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> To me:
> 
> void func(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5) {}
> 
> is much easier (and less error prone) then:
> 
> void func() {func();}
> void func(int a) {func(a,2);}
> void func(int a, int b) {func(a,b,3);}
> void func(int a, int b, int c) {func(a,b,c,4);}
> void func(int a, int b, int c, int d) {func(a,b,c,d,5);}
> void func(int a, int b, int c, int d, int e) {}

:-) Very convincing example. The error is in the first line. And now to the counter example. In which of the following lines of usage, i.e. calls, is the error?

   func( 1, 2, 3, 4, 6);
   func( 1, 2, 3, 4, 6);
   func( 1, 2, 3, 4, 6);
   func( 1, 2, 3, 4, 6);
   func( 1, 2, 3, 4, 6);

Did you stop the time you have needed to find it? Then multiply it with
the total number of lexical occurences of calls of `func', subtract
1, ... [some of the calculations intentionmally omitted] ..., finally
multiply it with the appropriate hourly wage. Are you sure, that
the resulting amount of money is less than your wage for writing five more
lines of code?

Note: I would have found your error, even without the commenting line above it.


[...]
> Remembering 9 parameters is much worse then only needing to remember 4 or less.

This is general wisdom, not related to the stated problem. Are you aware of the facts,

1) that the user must remember the default values of all nine default valued parameters to be able to decide, whether he is forced to overwrite it?

2) that he must remember and _type_ all preceding, up to eight, default values, if he detects that, the value of the ninth has to be overriden?

3) that any reviewer must _read_ up to eight values and compare
them with remembered default values for only finding that they indeed are
the default values, whereas the ninth has been overridden?


> IMHO having more available ways of using a function is like being about to write an equation in different ways. ie
> 
> a * b + c // is basicly the same as
> c + a * b

:-) I am quite sure, that you know, that this sequences of character beeing the same depends strongly on the rules that are applied to them.


> Why should be limit the way functions can be called?

Again I am quite sure, that you know several limits. And one of them is, that a function call is not allowed to be ambiguous.


> In your example case it is a design issue not a language issue.

Why do you think so? At which point a design issue turns to be a language issue?


> Another advantage of optional parameters is that they help force the different calls to behave the same way.

I do not see any justification for this claim. Is this claim consistent with the implicit message issued by your question, why function calls should be limited?


>>As far as you have managed that please explain why your arguments also hold, when applied to far more complex cases, than that which I am able to present to you within limited time and space.
> In the simple example I showed before, you only need to look at one line and know how to use it.  You also only need to look at one bit of documentation.  You don't need to look though pages of code to find out if a particular overload is provided.

??? I dont see a connection between my request and your reply.


>> Incredible more complex :-)
> That would be ok also except is this runtime?

I do not catch fully what you mean. There is no magic in my suggestion. The point/phase of execution will not be changed by my suggestion.

> On one hand you don't want optional parameters but then you want the ultimate dynamic optional parameters?

I do not want default valued parameters, as requested by the OP. I have not established a conviction on optional parameters. They are only a special case of the general possibilities of the D language. Because I had something totally different in mind, somebody could come up with the claim, that the usage of my suggested generalization for optional parametrs is an absue.

>>>It could cause overloading problems but I still would like this.
>>Until that case, in which you were unable to detect why the compiler refuses to compile your code.
> Again a design issue.

Agreed.


>>Note: you did not explain, why default valued parameters should be restricted to basic types. Is there a reason to refuse a default value for a function or delegate variable?
> Did I say that?
No. And I only ask :-)

>  If I have it would have only been to make the job
> easier on Walter however optional everything I say.

And with my suggestion also this is possible---by two or three minor changes to the language.

So long!

Manfred Nowak wrote:

>J Anderson wrote:
>
>  
>
>>To me:
>>
>>void func(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5) {}
>>
>>is much easier (and less error prone) then:
>>
>>void func() {func();} //should be {func(1);}
>>void func(int a) {func(a,2);}
>>void func(int a, int b) {func(a,b,3);}
>>void func(int a, int b, int c) {func(a,b,c,4);}
>>void func(int a, int b, int c, int d) {func(a,b,c,d,5);}
>>void func(int a, int b, int c, int d, int e) {}
>>    
>>
>
>:-) Very convincing example. The error is in the first line.
>
Just trying to make my point. I hoped you'd spot it :)

>And now to the counter example. In which of the following lines of usage, 
>
>i.e.
>calls, is the error?
>
>   func( 1, 2, 3, 4, 6);
>   func( 1, 2, 3, 4, 6);
>   func( 1, 2, 3, 4, 6);
>   func( 1, 2, 3, 4, 6);
>   func( 1, 2, 3, 4, 6);
>
>Did you stop the time you have needed to find it? Then multiply it with
>the total number of lexical occurences of calls of `func', subtract
>1, ... [some of the calculations intentionmally omitted] ..., finally
>multiply it with the appropriate hourly wage. Are you sure, that
>the resulting amount of money is less than your wage for writing five more
>lines of code?
>  
>
You could use this argument for making any line of code bigger in any language.  Therefore why not omit every bit of syntax sugar? Also generally it's not five lines.  One class could have many optional parameters.  In fact every method could in some cases.

More code is harder to read. 

>Note: I would have found your error, even without the commenting line
>above it.
>
>[...]
>  
>
>>Remembering 9 parameters is much worse then only needing to remember 4
>>or less.
>>    
>>
>
>This is general wisdom, not related to the stated problem. Are you aware
>of the facts,
>
>1) that the user must remember the default values of all nine
>default valued parameters to be able to decide, whether he is forced
>to overwrite it?
>  
>
I see this differently.  Optional characters are additions.  The user shouldn't need to know them unless they require them.  For example if decimal point was to be implemented with to string float it could be written as toString(float, int t = -1).  Much of the time you wouldn't even care that t = -1 exists.  If they need it there is only one place to look. 

On the design side if someone decided to change toString to toStringf (without optional parameters) then they'd need to go and find all the versions of toString that are used for floats and change them.  Because there are also toString's for int this makes things more difficult.  Ok that was only a simple example as things can get much more complex.  It's not like you can set-up a constant name (well in C++ you could with macros) and just change things in one place.

I like less redundant code because it is easier to maintain.

-- 
-Anderson: http://badmama.com.au/~anderson/

It's not common nor good to have so many default arguments per method. I can't recall using them much. At most one or 2 and in not so many places per project. I would say that if one needs so many default arguments, there is something *really* wrong with their design!

It reminds me of someone having complained that if the module would have 1000 imports, one would have to write out each of every one of them. :>

-eye

J Anderson schrieb:
> Manfred Nowak wrote:
> 
>> J Anderson wrote:
>>
>>  
>>
>>> To me:
>>>
>>> void func(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5) {}
>>>
>>> is much easier (and less error prone) then:
>>>
>>> void func() {func();} //should be {func(1);}
>>> void func(int a) {func(a,2);}
>>> void func(int a, int b) {func(a,b,3);}
>>> void func(int a, int b, int c) {func(a,b,c,4);}
>>> void func(int a, int b, int c, int d) {func(a,b,c,d,5);}
>>> void func(int a, int b, int c, int d, int e) {}
>>>   
>>
>>
>> :-) Very convincing example. The error is in the first line.
>>
> Just trying to make my point. I hoped you'd spot it :)
> 
>> And now to the counter example. In which of the following lines of usage,
>> i.e.
>> calls, is the error?
>>
>>   func( 1, 2, 3, 4, 6);
>>   func( 1, 2, 3, 4, 6);
>>   func( 1, 2, 3, 4, 6);
>>   func( 1, 2, 3, 4, 6);
>>   func( 1, 2, 3, 4, 6);
>>
>> Did you stop the time you have needed to find it? Then multiply it with
>> the total number of lexical occurences of calls of `func', subtract
>> 1, ... [some of the calculations intentionmally omitted] ..., finally
>> multiply it with the appropriate hourly wage. Are you sure, that
>> the resulting amount of money is less than your wage for writing five more
>> lines of code?
>>  
>>
> You could use this argument for making any line of code bigger in any language.  Therefore why not omit every bit of syntax sugar? Also generally it's not five lines.  One class could have many optional parameters.  In fact every method could in some cases.
> 
> More code is harder to read.
> 
>> Note: I would have found your error, even without the commenting line
>> above it.
>>
>> [...]
>>  
>>
>>> Remembering 9 parameters is much worse then only needing to remember 4
>>> or less.
>>>   
>>
>>
>> This is general wisdom, not related to the stated problem. Are you aware
>> of the facts,
>>
>> 1) that the user must remember the default values of all nine
>> default valued parameters to be able to decide, whether he is forced
>> to overwrite it?
>>  
>>
> I see this differently.  Optional characters are additions.  The user shouldn't need to know them unless they require them.  For example if decimal point was to be implemented with to string float it could be written as toString(float, int t = -1).  Much of the time you wouldn't even care that t = -1 exists.  If they need it there is only one place to look.
> On the design side if someone decided to change toString to toStringf (without optional parameters) then they'd need to go and find all the versions of toString that are used for floats and change them.  Because there are also toString's for int this makes things more difficult.  Ok that was only a simple example as things can get much more complex.  It's not like you can set-up a constant name (well in C++ you could with macros) and just change things in one place.
> 
> I like less redundant code because it is easier to maintain.
> 

Manfred Nowak wrote:
 > This is general wisdom, not related to the stated problem. Are you aware
> of the facts,
> 
> 1) that the user must remember the default values of all nine
> default valued parameters to be able to decide, whether he is forced
> to overwrite it?

Not if the function was well written. If the function developer is even moderately sane then the defaults will be chosen so that the function will work as intended if you just ignore the corresponding parameters. After all, a default value usually indicates that the function has a feature that you CAN use, but don't have to use.

> 2) that he must remember and _type_ all preceding, up to eight, default
> values, if he detects that, the value of the ninth has to be overriden?

Depends on the syntax. That is one of the weak points in C++, but there have already been some good suggestions on how to avoid that.
In any case, this issue also applies to the workaround of writing n dummy functions to emulate default parameters (at least if the parameters have the same type).

> 3) that any reviewer must _read_ up to eight values and compare
> them with remembered default values for only finding that they indeed are
> the default values, whereas the ninth has been overridden?   

See 2.


Default values are very important if you want to write good software libraries. A good library provides lots of functionality but is also easy to use. And to be easy to use one needs some mechanism to be able to hide/ignore unwanted functionality. In the case of functions that usually means that you need default values. These can be either implemented with a hack (like writing several dummy functions) or cleanly by supporting this directly in the language.

To give an example: most people agree that the standard libraries of Python are well designed and exceptionally easy to use. Why is that? If you read the documentation you will see that many function parameters have useful default values. The functions CAN do powerful and complicated things, but if you just want to use a simple subset of this functionality you can simply leave out the parameters that you don't need. And you don't even have to know how these WOULD be used either, since you can depend on the defaults to be the right ones.


Hauke