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 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.

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

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> 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.

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; }
> }
> 

"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

> 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

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
>
>

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