Thread overview
Does D support default arguments?
Jul 05, 2003
Andrew Edwards
Jul 05, 2003
Andrew Edwards
Jul 05, 2003
Andrew Edwards
Jul 06, 2003
Andrew Edwards
Jul 05, 2003
Ilya Minkov
July 05, 2003
If so, how does one use this feature?

Thanks in advance,
Andrew


July 05, 2003
"Andrew Edwards" <edwardsac@spamfreeusa.com> escribió en el mensaje
news:be5863$ibk$1@digitaldaemon.com...
|

No, it doesn't. You should use function overloading. Instead of:

int foo(int a,int b=0) {...}

You should write:

int foo(int a) { foo(a,0); }
int foo(int a,int b) { ....}

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.496 / Virus Database: 295 - Release Date: 2003-07-03


July 05, 2003
"Carlos Santander B." <carlos8294@msn.com> wrote in message news:be5a2l$jrq$1@digitaldaemon.com...
> "Andrew Edwards" <edwardsac@spamfreeusa.com> escribió en el mensaje
> news:be5863$ibk$1@digitaldaemon.com...
> |
>
> You should write:
>
> int foo(int a) { foo(a,0); }
> int foo(int a,int b) { ....}
>
how does this apply to the following situation?

class someClass
{
    this()
    {
      void func(){}
    }

    this(inout uint t)
    {
      void func(inout uint t){}
    }

    this(inout uint t, inout z)
    {
      void func(inout uint t, inout uint z){}
    }

    // suggested fix
    this(inout uint t)
    {
      func(t, 0);
    }
}

I would like to provide a default argument for z; however, since I've already overloaded this(inout uint t) to do something else, overloading it again as suggested would result in ambiguity. Wouldn't it?


July 05, 2003
Sorry...

>     // suggested fix
>     this(inout uint t)
>     {
>       func(t, 0);
>     }

should read:


     // suggested fix
     this(inout uint t)
     {
       this(t, 0);
     }


July 05, 2003
"Andrew Edwards" <edwardsac@spamfreeusa.com> escribió en el mensaje
news:be5cnt$m25$1@digitaldaemon.com...
| how does this apply to the following situation?
|
| class someClass
| {
|     this()
|     {
|       void func(){}
|     }
|
|     this(inout uint t)
|     {
|       void func(inout uint t){}
|     }
|
|     this(inout uint t, inout z)
|     {
|       void func(inout uint t, inout uint z){}
|     }
|
|     // suggested fix
|     this(inout uint t)
|     {
|       func(t, 0);
|     }
| }
|

That's really odd (for me, at least), because you need an inout parameter, so there's no logical reason for having it as default, because it must be a reference. About having two identical functions, well, they should do the same thing, shouldn't they? I mean, they're both constructors, so they should be behaving *at least* in similar ways.

————————————————————————— Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 2003-07-04


July 05, 2003
Andrew Edwards wrote:

> I would like to provide a default argument for z; however, since I've
> already overloaded this(inout uint t) to do something else, overloading it
> again as suggested would result in ambiguity. Wouldn't it?

Default arguments are also a kind of overloading in C++. You can imagine that like simple functions which are generated in-line.

Taken the call

	func(t, 0);

how should it be supposed to know, which function to choose??? Both are perfectly good substitutes.

consider another stupid situation:

	func(t, 0, 3);

It knows that it is to choose the function with 3 parameters. However, the parameter where 3 is passed is inout, which means a function can write into it. 3 is a constant. How do you write into a constant? And this is the kind of expansion which is done for default parameters.

What you probably want is a global variable, which you shall pass into the function, or use the first overloaded one, or DISAMBIGUATE NAMES.

Mind: overusing overloading will bite you, since in case you are assigning different behaviour to overloads, you need to think at any function call what function exactly is called, and why exactly some other overload is not. Even if you manage to get it right, adding another overloaded form will most certainly break your code.

-i.

July 06, 2003
"Carlos Santander B." <carlos8294@msn.com> wrote...

> That's really odd (for me, at least), because you need an inout parameter, so there's no logical reason for having it as default, because it must be
a
> reference. About having two identical functions, well, they should do the same thing, shouldn't they? I mean, they're both constructors, so they should be behaving *at least* in similar ways.

For the inexperienced, nothing seems "odd" the first time around! I guess have a lot of learning left to do. Given time, and people like yourself who take time to answer my brain-dead question, I will get the hang of this!

The previous example was my closest "guestimation" of what was happening in a C++ program. Learning has occurred!

Thanks,
Andrew