What's the technical reason that class ctors aren't virtual?

[Ary Manzana]

On 8/24/11 12:27 PM, Ali Çehreli wrote:
> On Wed, 24 Aug 2011 16:59:46 +0200, Andrej Mitrovic wrote:
>
>> class Foo
>> {
>>      this(int x, int y) { }
>> }
>>
>> class Bar : Foo
>> {
>> }
>>
>> Bar has to define its own ctor even if it only forwards the call to the
>> super() ctor, e.g.:
>>
>> class Bar : Foo
>> {
>>      this(int x, int y) { super(x, y); }
>> }
>
> That's because it is Bar that constructs its Foo part. The user
> constructs a Bar and must provide only what Bar needs, potentially
> nothing:
>
> class Bar : Foo
> {
>      this() { super(42, 43); }
>
>> But I'm curious why this works this way.
>
> Another reason would be function hijacking: Subtle changes in types of
> contsructor parameters might bypass derived constructors just becaues
> they now match better to the super's.
>
>> If I have a large inheritance
>> tree of classes and I want to change the base class ctor (say I want to
>> add another int as a parameter), I'll have to change all the ctors in
>> the subclasses as well.
>>
>> Isn't that counterproductive?
>
> Sounds like it but is necessary: Which of the constructors of the derived
> constructors should the compiler call after calling super's matching one?
> If it didn't, the derived parts would be left unconstructed.
>
> Ali

I was against this feature but Ruby implements it and I love it. I see 
no technical reason not to do it. The rule should be: if the class 
doesn't provide any constructor, just copy the constructors from the 
base class.