There is a trend in recent languages (Java, C#, D,...) to not support default arguments. I use them all the time in C++, so I don't like this at all. Writing 5 versions of a single function just to make calling it more convenient gets very annoying after some time and it also reduces code readability quite a bit.

Is there some technical reason why we can't have default arguments?

It seems to me that even if it is for some reason impossible to implement "real" default args in these languages (though I can't imagine why that would be the case), it would still be possible to let the compiler automatically generate the corresponding dummy functions if a default value for an argument is specified.

So, what's the deal with this?


Hauke

I don't think default arguments present any technical difficulty. If they will be implemented, I propose that the method call to be like this:

<method>(,,,<arg>,,,)

In other words, parameters can be omitted if there is a default value for them.

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bvtrjq$1p0$1@digitaldaemon.com...
> There is a trend in recent languages (Java, C#, D,...) to not support default arguments. I use them all the time in C++, so I don't like this at all. Writing 5 versions of a single function just to make calling it more convenient gets very annoying after some time and it also reduces code readability quite a bit.
>
> Is there some technical reason why we can't have default arguments?
>
> It seems to me that even if it is for some reason impossible to implement "real" default args in these languages (though I can't imagine why that would be the case), it would still be possible to let the compiler automatically generate the corresponding dummy functions if a default value for an argument is specified.
>
> So, what's the deal with this?
>
>
> Hauke

Hauke Duden wrote:
> There is a trend in recent languages (Java, C#, D,...) to not support default arguments. I use them all the time in C++, so I don't like this at all. Writing 5 versions of a single function just to make calling it more convenient gets very annoying after some time and it also reduces code readability quite a bit.
> 
> Is there some technical reason why we can't have default arguments?
> 
> It seems to me that even if it is for some reason impossible to implement "real" default args in these languages (though I can't imagine why that would be the case), it would still be possible to let the compiler automatically generate the corresponding dummy functions if a default value for an argument is specified.
> 
> So, what's the deal with this?
> 
> 
> Hauke

I'd rather have argument passing by keyword and variable length arguments.

my 1 (euro)cent,

bye,
roel

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bvtrjq$1p0$1@digitaldaemon.com...
> There is a trend in recent languages (Java, C#, D,...) to not support default arguments. I use them all the time in C++, so I don't like this at all. Writing 5 versions of a single function just to make calling it more convenient gets very annoying after some time and it also reduces code readability quite a bit.
>
> Is there some technical reason why we can't have default arguments?

probably not. Though see items 24 and 38 in Scott Meyer's Effective C++ for things to watch out for (namely, overloading vs default arguments and static vs dynamic binding of default arguments). Fortran kindof supports it by letting users omit arguments and making the function body fill in a default if the value wasn't supplied,

> It seems to me that even if it is for some reason impossible to implement "real" default args in these languages (though I can't imagine why that would be the case), it would still be possible to let the compiler automatically generate the corresponding dummy functions if a default value for an argument is specified.
>
> So, what's the deal with this?

When using defaults it pretty often happens that you want to specify only some of the defaults. IIRC C++ fills in defaults for whatever arguments haven't been used up. Fortran works around this by allowing unused arguments to be picked out by name. For example (in pseudo-code) given a function with default arguments

 void foo(int a, int b=1, int c=2, int d=3) {...}

then calling it with

 foo(10,c=4)

will have a=10, b=1,c=4,d=3.
Does any of stuff belong in D? I can live without it. I've gotten used to
living without it in Java.

-Ben

Ben Hinkle wrote:
>>Is there some technical reason why we can't have default arguments?
> 
> probably not. Though see items 24 and 38 in Scott Meyer's Effective C++ for
> things to watch out for (namely, overloading vs default arguments and static
> vs dynamic binding of default arguments).

I'm not familiar with this book, but I think not having default arguments makes function overloading worse. For example, if you have 5 functions instead of one and you want to overload them, you either have to rely on the internal knowledge that 4 of these just call the fifth function (which is bad), or you have to overload all 5 (which is also bad).

If you meant the problem of what to do if different default arguments are specified for overloads: this could simply be illegal. I never had this problem in C++ in the decade that I use this language, but I guess it is something that a compiler could simply forbid.

> Does any of stuff belong in D? I can live without it. I've gotten used to
> living without it in Java.

I found that when I'm writing applications I could also live without it, because everything tends to be rather specific to what I need. In other words: if an argument is not needed in my application I just leave it out completely.

But when I'm writing libraries I just hate not having default arguments. Since libraries are designed for the general case, you want to give the user flexibility but at the same time give him a convenient way of calling the function if that flexibility is not needed. That's where default arguments are very useful. I tried to write a small library in D the other day and I ended up providing six(!) versions of a function just to allow the user to leave out unnecessary arguments.

In my opinion, this kind of mechanic task is what the compiler is supposed to do for me in a high level language!

Hauke

Hauke Duden wrote:
> There is a trend in recent languages (Java, C#, D,...) to not support default arguments. I use them all the time in C++, so I don't like this at all. Writing 5 versions of a single function just to make calling it more convenient gets very annoying after some time and it also reduces code readability quite a bit.
> 
> Is there some technical reason why we can't have default arguments?

Walter's concerning about the complexity of relating rules to

I think it might be late to get this in D 1.0, but if we come up with compelling enough arguments, I think we could get this into D 2.0.

Walter doesn't seem to be dead-set against it, but it's not his particular coding style, so we'll have to give some examples of how useful it is.  More importantly, the rules would have to be developed how default arguments might coexist with function overloads.

As for my opinion, I'd love to have default arguments in D, but I appreciate Walter's concerns and no one (as far as I know) has proprosed a way to fit function overloading and default arguments in a simple scheme.

I've including some references to the older conversations you might want to take a look at.


General
http://www.digitalmars.com/drn-bin/wwwnews?D/19377
http://www.digitalmars.com/drn-bin/wwwnews?D/294

Pros (Count me in this camp)
http://www.digitalmars.com/drn-bin/wwwnews?D/1663
http://www.digitalmars.com/drn-bin/wwwnews?D/1662
http://www.digitalmars.com/drn-bin/wwwnews?D/19377
http://www.digitalmars.com/drn-bin/wwwnews?D/19378
http://www.digitalmars.com/drn-bin/wwwnews?D/528
http://www.digitalmars.com/drn-bin/wwwnews?D/883
http://www.digitalmars.com/drn-bin/wwwnews?D/2476
http://www.digitalmars.com/drn-bin/wwwnews?D/2478

Cons (Walter's concerns)
http://www.digitalmars.com/drn-bin/wwwnews?D/1114
http://www.digitalmars.com/drn-bin/wwwnews?D/439
http://www.digitalmars.com/drn-bin/wwwnews?D/2474
http://www.digitalmars.com/drn-bin/wwwnews?D/2477
http://www.digitalmars.com/drn-bin/wwwnews?D/2479

On the fence?
http://www.digitalmars.com/drn-bin/wwwnews?D/19439

> 
> It seems to me that even if it is for some reason impossible to implement "real" default args in these languages (though I can't imagine why that would be the case), it would still be possible to let the compiler automatically generate the corresponding dummy functions if a default value for an argument is specified.
> 
> So, what's the deal with this?
> 
> 
> Hauke

-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:
> Walter's concerning about the complexity of relating rules to

I'm not sure I understand what these complexities are. They are not explained in the posts you provided links to (thanks for the links - I missed that conversation entirely!).

If it's only the problem of different defaults being specified for overloads: I could live very well with it if the compiler mandates that if there is a default value for an argument of the base function, then there must be the same default value for that argument in all overloads. That also makes sense for readability and consistency.

> Walter doesn't seem to be dead-set against it, but it's not his particular coding style, so we'll have to give some examples of how useful it is.

I often use them in constructors and functions that create objects. But they're also useful for algorithms that have parameters which are often the same, but sometimes have to be different. Here are some examples:

Request sendHTTPRequest(String request,Addr dest, int port=80, HeaderFields additionalFields=null, bool bAutoClose=true);

int stringFind(String findIn,String findWhat,int from=0,int length=-1,int flags=CaseSensitive);

Connection createDatabaseConnection(URI host,String user=null,String password=null,String defaultDB=null);

void quickSort(List elements,CompareFunc cmp=null);

If you want more examples just say so ;).

I'm very surprised that Walter uses default arguments that rarely (as he states in one of the linked posts). He even says that usually it is only one default argument. It is completely different with the kind of stuff I write - I use them all the time and I quite often have 2-3 defaults, sometimes even more. But as I said in another post, this usually occurs when I write general purpose libraries. Maybe Walter just doesn't write such libraries?


Hauke

Thanks for your response.

My reply is embeded thoughout...

Hauke Duden wrote:
> J C Calvarese wrote:
> 
>> Walter's concerning about the complexity of relating rules to
> 
> 
> I'm not sure I understand what these complexities are. They are not explained in the posts you provided links to (thanks for the links - I missed that conversation entirely!).

I think I understand his concerns, but I may not be able to explain it correctly. But I'll try anyway.

Let's say you have a function (I guess I can't discuss anything without creating an example)...

HWND CreateForm(HWND parent, char[] title, int height, int width, int xPos, int yPos, int style)
{
  // insert implementation here.
}

Well, if defaults were an option, then you'd rewrite the above code including defaults...

HWND CreateForm(HWND parent, char[] title="My Window", int height=100, int width=200, int xPos=5, int yPos=5, int style=MY_FAVORITE_STYLE)
{
  // insert implementation here.
}

Well, if someone wanted to write ambiguous code, they could try to overload it, too.

HWND CreateForm(HWND parent, char[] title, int height, int width, int xPos, int yPos)
{
  CreateForm(parent, title, height, width, xPos, yPos,   	
  MY_FAVORITE_STYLE);
}

HWND CreateForm(HWND parent, char[] title, int height, int width, int xPos)
{
  CreateForm(parent, title, height, width, xPos, 5, MY_FAVORITE_STYLE);
}

HWND CreateForm(HWND parent, char[] title, int height, int width)
{
  CreateForm(parent, title, height, width, 5, 5,
   MY_FAVORITE_STYLE);
}

HWND CreateForm(HWND parent, char[] title, int height)
{
  CreateForm(parent, title, height, 100, 5, 5, MY_FAVORITE_STYLE);
}


My example is trivial (and insanely redundant) because I'm telling the compiler to do the same exact thing twice, but in real use I'm sure the unorganized programmer would likely be specifying different defaults.

In the default argument he uses a width of 100, but in the overload he specifies a width of 150.  Now it matters whether the compiler spits out an error or guesses at the programmer's meaning.

Which default did he intend?  So the we need to decide what would be an error or what should override what? It kind of hurts my head trying to what should the compiler do with this code, so this might be part of what Walter doesn't want to worry about (by not having default arguments).

And then we look at inheritance.  Does it inherit the default arguments?  Do we want it to inherit? Ewww...

I'm not sure if this is the worst part of adding default arguments, but it does give me reason for concern. I suspect Walter won't consider adding this feature unless there's a strong consensus on these issues.

> If it's only the problem of different defaults being specified for overloads: I could live very well with it if the compiler mandates that if there is a default value for an argument of the base function, then there must be the same default value for that argument in all overloads. That also makes sense for readability and consistency.

I don't think it's obvious to the compiler whether we're consistent or not.  It sees we're doing both, but I don't know if the compiler is intuitive enough to see if the result would be the same.

Maybe we can overload OR use defaults, but we can't do both with a particular function? (I'm just thinking out loud.)

> 
>> Walter doesn't seem to be dead-set against it, but it's not his particular coding style, so we'll have to give some examples of how useful it is.
> 
> 
> I often use them in constructors and functions that create objects. But they're also useful for algorithms that have parameters which are often the same, but sometimes have to be different. Here are some examples:
> 
> Request sendHTTPRequest(String request,Addr dest, int port=80, HeaderFields additionalFields=null, bool bAutoClose=true);
> 
> int stringFind(String findIn,String findWhat,int from=0,int length=-1,int flags=CaseSensitive);
> 
> Connection createDatabaseConnection(URI host,String user=null,String password=null,String defaultDB=null);
> 
> void quickSort(List elements,CompareFunc cmp=null);
> 
> If you want more examples just say so ;).

(You don't have to convince me.  I like default arguments. :) )

> 
> I'm very surprised that Walter uses default arguments that rarely (as he states in one of the linked posts). He even says that usually it is only one default argument. It is completely different with the kind of stuff I write - I use them all the time and I quite often have 2-3 defaults, sometimes even more. But as I said in another post, this usually occurs when I write general purpose libraries. Maybe Walter just doesn't write such libraries?

Perhaps not.

> 
> 
> Hauke

-- 
Justin
http://jcc_7.tripod.com/d/

Hauke Duden wrote:
> Ben Hinkle wrote:
> 
>>> Is there some technical reason why we can't have default arguments?
>>
>>
>> probably not. Though see items 24 and 38 in Scott Meyer's Effective C++ for
>> things to watch out for (namely, overloading vs default arguments and static
>> vs dynamic binding of default arguments).
> 
> 
> I'm not familiar with this book, 

You can have a look at item 24 for free here
http://www.awprofessional.com/content/downloads/meyerscddemo/DEMO/EC/EI24_FR.HTM

Bastiaan.

Achilleas Margaritis wrote:
> I don't think default arguments present any technical difficulty. If they
> will be implemented, I propose that the method call to be like this:
> 
> <method>(,,,<arg>,,,)
> 
> In other words, parameters can be omitted if there is a default value for
> them.

Now that's readable ;)  If D were to support arbitrary default arguments I'd much prefer some sort of signifier:

<method>( default, default, <arg>, default, default )

If they were C++-style defaults then I'm abivalent.


Sean