Re: inheriting constructos

[Denis Koroskin]

On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu  
<seewebsiteforem...@erdani.org> wrote:

Denis Koroskin wrote:
On Mon, 30 Nov 2009 02:20:40 +0300, bearophile  
<bearophileh...@lycos.com> wrote:

Andrei Alexandrescu:
c) If a class doesn't define any constructors but does add at least a
non-static field -> undecided.

Does 'undecided' mean 'compile-time error'?"

Bye,
bearophile
 I think it means they are not decided whether it should inherit  
constructors.
 Back on topic, I do think inheriting constructors is a good idea, even  
in presence of additional fields (why not?)
 I also think constructor inheritance could be implemented without any  
changes to the language the following way:
 this(Args...)(Args args) if (__traits(compiles, super(args)))
{
    super(args);
     // initialize additional fields, if any present
    // and/or do some post-construction logic
}
 Why create new rules? :)

Alas, that doesn't work because of ref and out arguments. I actually  
think it's a language bug that it's impossible to implement perfect  
forwarding.

Andrei

Well, intuitively it should be implemented this way:

class Foo { /* a few different ctors */ }

class Bar : Foo
{
    alias super.this this; // the same way you do
    // "alias super.someMethod someMethod;" to add someMethod into current  
scope
}

Unfortunately, this conflicts with alias this feature. If we could rename  
constructors from "this" to "ctor", we could use it with no ambiguity:

class Bar : Foo
{
    alias super.ctor ctor;

    ctor(Other other)
    {
       // ... shoudn't conflict with existing ctors (or should it?)
    }
}

This would also help getting rid an ugly "__ctor" identifier which is used  
as placement new:

void[] mem = allocate!(T);

// old style
T.__ctor(mem);

// new style
T.ctor(mem);