class v
{
   this()
   {}
}

This "this" conflicts with the concept of "alias this" in D2.0

class base
{
    ctor()
    {
    }
}

class inherit:base
{
   alias base.ctor ctor; // bring up the ctor to overload, iirc, there were people who called for this feature
    ctor(int i)
   {
   }
}

so I can do:
auto inst = new inherit();
auto inst1 = new inherit(34);

Instead, you can do this:

class inherit : base
{
    ctor(int i) { }
    ctor() { super(); }
}

Walter Bright Wrote:
> Instead, you can do this:
> 
> class inherit : base
> {
>      ctor(int i) { }
>      ctor() { super(); }
> }

Yes, but it gets uncomfortable when you want to forward more constructors:

class base {
  ctor(int never, MyTemplate!(float, 3, "abcd") ending, char[] parameter = "abcd", int list = 3) {}
  ctor(float including, int defaults = 3) {}
}

class derived : base {
  ctor(int never, MyTemplate!(float, 3, "abcd") ending, char[] parameter = "abcd", int list = 3)
  { super(never, ending, parameter, list); }
  ctor(float including, int defaults = 3)
  { super(including, defaults); }
}

plus you have to replicate default values and make sure you update all derived classes when changing the base constructors. I.e. the same arguments that explain why you can use alias to bring base class member functions into the overload set apply to the constructor. Also, sometimes the base class constructors are unknown:

class C(T) : T { this(?) { super(?); }

I guess these issues could also be solved using a mixin if there was a way to enumerate constructors at compile time, but there's another advantage to renaming 'this' to a non-keyword name: you allow getting its address and using it as a template alias parameter.

在 Wed, 01 Apr 2009 18:36:56 +0800，Christian Kamm <kamm-incasoftware@shiftatleftanddelete.de> 写道:

> Walter Bright Wrote:
>> Instead, you can do this:
>>
>> class inherit : base
>> {
>>      ctor(int i) { }
>>      ctor() { super(); }
>> }
>
> Yes, but it gets uncomfortable when you want to forward more constructors:
>
> class base {
>   ctor(int never, MyTemplate!(float, 3, "abcd") ending, char[] parameter = "abcd", int list = 3) {}
>   ctor(float including, int defaults = 3) {}
> }
>
> class derived : base {
>   ctor(int never, MyTemplate!(float, 3, "abcd") ending, char[] parameter = "abcd", int list = 3)
>   { super(never, ending, parameter, list); }
>   ctor(float including, int defaults = 3)
>   { super(including, defaults); }
> }
>
> plus you have to replicate default values and make sure you update all derived classes when changing the base constructors. I.e. the same arguments that explain why you can use alias to bring base class member functions into the overload set apply to the constructor. Also, sometimes the base class constructors are unknown:
>
> class C(T) : T { this(?) { super(?); }
>
> I guess these issues could also be solved using a mixin if there was a way to enumerate constructors at compile time, but there's another advantage to renaming 'this' to a non-keyword name: you allow getting its address and using it as a template alias parameter.
>

Yeah, all the merits of ctor just outweigh its demerits. The only demerit of it is taking "ctor" to join the keyword list, However it also bans people from using ctor as a var( it might be positive! )

davidl Wrote:
> Yeah, all the merits of ctor just outweigh its demerits. The only demerit of it is taking "ctor" to join the keyword list, However it also bans people from using ctor as a var( it might be positive! )

If you make ctor a keyword that doesn't behave like an identifier almost everywhere, I fear you'll just replace 'this' by 'ctor' without much benefit. I can't see a good reason for the constructor function name to be a keyword. Maybe something like opCtor or opConstruct would fit better with the existing special functions though.

在 Wed, 01 Apr 2009 20:04:09 +0800，Christian Kamm <kamm-incasoftware@shiftatleftanddelete.de> 写道:

> davidl Wrote:
>> Yeah, all the merits of ctor just outweigh its demerits. The only demerit
>> of it is taking "ctor" to join the keyword list, However it also bans
>> people from using ctor as a var( it might be positive! )
>
> If you make ctor a keyword that doesn't behave like an identifier almost everywhere, I fear you'll just replace 'this' by 'ctor' without much benefit. I can't see a good reason for the constructor function name to be a keyword. Maybe something like opCtor or opConstruct would fit better with the existing special functions though.
>

Oh, right, you are pushing it further bit than I ;) I totally agree with you.

Walter Bright schrieb:
> Instead, you can do this:
> 
> class inherit : base
> {
>     ctor(int i) { }
>     ctor() { super(); }
> }

Yeah, don't unnecessarily bloat the language. D2 already has a freaking huge amount of features.

在 Wed, 01 Apr 2009 22:59:41 +0800，Trass3r <mrmocool@gmx.de> 写道:

> Walter Bright schrieb:
>> Instead, you can do this:
>>  class inherit : base
>> {
>>     ctor(int i) { }
>>     ctor() { super(); }
>> }
>
> Yeah, don't unnecessarily bloat the language. D2 already has a freaking huge amount of features.


?
This is a not *feature*
This is something about the suitable way to name the ctor