inheriting constructos
Denis Koroskin
2korden at gmail.com
Sun Nov 29 17:35:17 PST 2009
On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Denis Koroskin wrote:
>> On Mon, 30 Nov 2009 02:20:40 +0300, bearophile
>> <bearophileHUGS at 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);
More information about the Digitalmars-d
mailing list