• Evan McClanahan (13/13) Nov 12 2002 this doesn't compile:
• Burton Radons (2/18) Nov 12 2002 Default arguments aren't a part of the language.
• Evan McClanahan (4/26) Nov 12 2002 I see. Must have missed that. Is there any compelling reason not to
• Walter (13/16) Nov 12 2002 They aren't necessary with an optimizing compiler. For example, you coul...
• Sandor Hojtsy (12/28) Nov 13 2002 Not necessary from "executable file size and speed" point of view.
• Sab (7/8) Nov 23 2002 Seconded.
• Lloyd Dupont (25/33) Nov 23 2002 one thing puzzle me.
• Evan McClanahan (10/39) Nov 23 2002 It might be pretty clear, but I think that something like that should be...
• Sab (7/16) Nov 23 2002 Well, here the interface of a library has changed!
• Sandor Hojtsy (20/37) Nov 25 2002 I agree. Default parameter is part of the interface of the function.
• Farmer (30/37) Jan 11 2003 Here's another example why default parameters are evil, that I saw on a ...
• Mike Wynn (73/110) Jan 11 2003 I must remember that example,
• Walter (8/21) Nov 12 2002 You can write it as:
• Evan McClanahan (7/16) Nov 13 2002 Yeah, I figured that. I just thought that the defaults were a cleaner

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

this doesn't compile:


const int broken = 1;

class Classy
{
     	int internal;

	this(int i = broken)
	{
		internal = broken;
	}
}

as a placeholder example, of course.  there are ways of working around 
this, but it would be cleaner if it was allowed.

Evan

Burton Radons <loth users.sourceforge.net> writes:

Evan McClanahan wrote:
 this doesn't compile:
 
 const int broken = 1;
 
 class Classy
 {
         int internal;
 
     this(int i = broken)
     {
         internal = broken;
     }
 }
 
 as a placeholder example, of course.  there are ways of working around 
 this, but it would be cleaner if it was allowed.

Default arguments aren't a part of the language.

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Burton Radons wrote:
 Evan McClanahan wrote:
 
 this doesn't compile:

 const int broken = 1;

 class Classy
 {
         int internal;

     this(int i = broken)
     {
         internal = broken;
     }
 }

 as a placeholder example, of course.  there are ways of working around 
 this, but it would be cleaner if it was allowed.

 
 
 Default arguments aren't a part of the language.
 

I see.  Must have missed that.  Is there any compelling reason not to 
include them?

Evan

"Walter" <walter digitalmars.com> writes:

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:aqr3s5$7e1$1 digitaldaemon.com...
 Default arguments aren't a part of the language.

 I see.  Must have missed that.  Is there any compelling reason not to
 include them?

They aren't necessary with an optimizing compiler. For example, you could
write:

    foo(int i, int j)
    {
        ...
    }

    foo(int i)
    {
        foo(i, default_j);
    }

and the inlining will eliminate the extra function call.

"Sandor Hojtsy" <hojtsy index.hu> writes:

"Walter" <walter digitalmars.com> wrote in message
news:aqrjqk$o2d$2 digitaldaemon.com...
 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aqr3s5$7e1$1 digitaldaemon.com...
 Default arguments aren't a part of the language.

 I see.  Must have missed that.  Is there any compelling reason not to
 include them?

 They aren't necessary with an optimizing compiler. For example, you could
 write:

     foo(int i, int j)
     {
         ...
     }

     foo(int i)
     {
         foo(i, default_j);
     }

 and the inlining will eliminate the extra function call.

Not necessary from "executable file size and speed" point of view.
Hopefully there are also some other factors considered during a language
design.
Such as intuitive and concise language structure. Such as self
documentation.
And note the evil redundancy in the example. :-)
What's on the other side? Compiler simplicity?

I think the language would be better with default parameters enabled.

Yours,
Sandor

"Sab" <sab neuropolis.org> writes:

 I think the language would be better with default parameters enabled.

Seconded.

One nice feature I do appreciate in many other languages
is this simple and elegant way of optional initialization.
I, too, hope D will include this (suposedly cheap?) feature
in the future.

Thanks,
Sab

"Lloyd Dupont" <lloyd galador.net> writes:

one thing puzzle me.
isn't default parameter evil ?

let me explain and you told me why my example isn'ty relevent:

let say I build a library, shipped as a DLL (let's called it Answer.dll)
with a class
class A
{
    void myfunc(int i = 42) {}
}

you use it.
later the developer of Answer realize that 42 isn't the answer !
maybe it's 43 ?
so he rewrite
class A
{
    void myfunc(int i=43) {}
}


and you upgrade your work to use this dll. you don't need to compile again,
it's a dll !
Alas, nothing work well now, as your code use the old default value...

It seems to me that it's a pretty clear example showing default value are
evil.
don't you think ?


"Sab" <sab neuropolis.org> a écrit dans le message de news:
arnqvt$b8j$1 digitaldaemon.com...
 I think the language would be better with default parameters enabled.

 Seconded.

 One nice feature I do appreciate in many other languages
 is this simple and elegant way of optional initialization.
 I, too, hope D will include this (suposedly cheap?) feature
 in the future.

 Thanks,
 Sab

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Lloyd Dupont wrote:
 one thing puzzle me.
 isn't default parameter evil ?
 
 let me explain and you told me why my example isn'ty relevent:
 
 let say I build a library, shipped as a DLL (let's called it Answer.dll)
 with a class
 class A
 {
     void myfunc(int i = 42) {}
 }
 
 you use it.
 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }
 
 
 and you upgrade your work to use this dll. you don't need to compile again,
 it's a dll !
 Alas, nothing work well now, as your code use the old default value...
 
 It seems to me that it's a pretty clear example showing default value are
 evil.
 don't you think ?

It might be pretty clear, but I think that something like that should be 
  pretty rare.  Although that situation isn't unimaginable, I feel that 
it's rathat unlikely, seeing what default values are generally used for, 
   to end up as something like that.  In any case, D provides similar 
functionality in any case, or at least a workaround, so it seems like a 
non-issue to me, as your example is more of a case of working with a DLL 
  provided by a poor software developer than something that's language 
dependant.  Working with other people can always stick it to you...


Evan	

"Sab" <sab neuropolis.org> writes:

 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }

 and you upgrade your work to use this dll. you don't need to compile

again,
 it's a dll !


Well, here the interface of a library has changed!
So you *do* need to recompile. (Or otherwise get
the change propagated to the client stuff; obviously,
if a system silently swallows an interface conflict,
that stuff is simply broken.)

Sab

"Sandor Hojtsy" <hojtsy index.hu> writes:

"Sab" <sab neuropolis.org> wrote in message
news:arok6l$147i$1 digitaldaemon.com...
 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }

 and you upgrade your work to use this dll. you don't need to compile

 again,
 it's a dll !


 Well, here the interface of a library has changed!
 So you *do* need to recompile. (Or otherwise get
 the change propagated to the client stuff; obviously,
 if a system silently swallows an interface conflict,
 that stuff is simply broken.)

 Sab


I agree. Default parameter is part of the interface of the function.
And if there is no checking for interface conficts, you can easily cause
other errors:

class A
{
  void myfunc(int i);
}

later changed to

class A
{
  void myfunc(double i);
}

Now do you need to recompile the client side??

Please note that C++ already takes care of this. Since default parameters
are in the header files, changing them causes the client side to recompile.

Do you know any other reasons to label default parameters evil?

Yours,
Sandor

Farmer <itsFarmer. freenet.de> writes:

[snip]
 
 Do you know any other reasons to label default parameters evil?
 
 Yours,
 Sandor
 
 

Here's another example why default parameters are evil, that I saw on a C++ 
web site.


#include <stdio.h>
struct SomeBaseClass
{
   virtual void func(char* msg="Default parameters are EVIL.")
   {
      printf("%s\n", msg);
   }
};

struct SomeClass : public SomeBaseClass
{
   virtual void func(char* msg="Default parameters would be great for D.")
   {
      SomeBaseClass::func(msg);
   }
};

int main(char*, char*[])
{
   SomeBaseClass* p=new SomeClass();
   p->func();  // print "Default parameters would be great for D." 
   return 0;
}

The output of this program is "Default parameters are EVIL." !!
It is not "Default parameters would be great for D." as one expects at the 
first glance.

If this code is translated to D (with default parameters added), the same 
BUG will exist.



Farmer

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

I must remember that example,
lack of default params in Java annoyed me for the first few weeks of Java
programming, then you get used to putting in a few more methods;

it could be argued that the compile could create the methods for you rather
than "defaulting" the params
so the D (with "predefined" params) would be
 class SomeBaseClass
 {
    void func(char[] msg="Default parameters are EVIL.")
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func(char[] msg="Default parameters in D would could be better that
C++." )
    {
        SomeBaseClass::func(msg);
    }
};

which would create (in effect)

 class SomeBaseClass
 {
    void func()
    {
       func("Default parameters are EVIL.")
    }
    void func(char[] msg)
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func()
    {
        func("Default parameters would be great for D.");
    }
    void func(char[] msg="Default parameters in D would could be better that
C++.")
    {
        SomeBaseClass::func(msg);
    }
};

so

int main( char[][] )
{
    SomeBaseClass p = new SomeClass();
    p.func();  // will now print print "Default parameters in D would could
be better that C++."
    return 0;
}

obviously it's the same as C++ that only the end params can be "predefined"
class c {
int func( int a, int b =1, int c) {.. } // this is not allowed. 'c' must be
"predefined" too if you want to predefine 'b'
}

so
class c {
int func( int a, int b =1, int c = 2 ) {.. }
}
would expand to

class c {
int func( int a, int b, int c ) {.. }
int func( int a, int b, ) { return func(a, b, 2); }
int func( int a, ) { return func(a, 1, 2); }
}

that's not to say I agree with default/predefined params, but offer a
slighty less error prone solution if you must have them.

"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns9300BD258659itsFarmer 63.105.9.61...
 [snip]
 Do you know any other reasons to label default parameters evil?

 Yours,
 Sandor

 Here's another example why default parameters are evil, that I saw on a

C++
 web site.


 #include <stdio.h>
 struct SomeBaseClass
 {
    virtual void func(char* msg="Default parameters are EVIL.")
    {
       printf("%s\n", msg);
    }
 };

 struct SomeClass : public SomeBaseClass
 {
    virtual void func(char* msg="Default parameters would be great for D.")
    {
       SomeBaseClass::func(msg);
    }
 };

 int main(char*, char*[])
 {
    SomeBaseClass* p=new SomeClass();
    p->func();  // print "Default parameters would be great for D."
    return 0;
 }

 The output of this program is "Default parameters are EVIL." !!
 It is not "Default parameters would be great for D." as one expects at the
 first glance.

 If this code is translated to D (with default parameters added), the same
 BUG will exist.



 Farmer

"Walter" <walter digitalmars.com> writes:

You can write it as:

class Classy
{    int internal = 1;

    this() { ... }
    this(int i) { internal = i; }
}

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:aqr0p6$4c9$1 digitaldaemon.com...
 this doesn't compile:


 const int broken = 1;

 class Classy
 {
      int internal;

 this(int i = broken)
 {
 internal = broken;
 }
 }

 as a placeholder example, of course.  there are ways of working around
 this, but it would be cleaner if it was allowed.

 Evan

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Yeah, I figured that.  I just thought that the defaults were a cleaner 
way to write that.  However, it's a small and seldom encountered enough 
  thing that I don't care much.  I was just under the assumption that 
they would be in the language and they weren't.  It's easy enough to 
work around that it doesn't bother me.


Evan


Walter wrote:
 You can write it as:
 
 class Classy
 {    int internal = 1;
 
     this() { ... }
     this(int i) { internal = i; }
 }