Constructor Propagation

[gafter]

@TonyValenti commented on Thu Jan 28 2016

Right now if a base class has a constructor with parameters, all derived classes have to basically reimplement the constructor even if there is no functional change. If a class does not specify ANY constructors, I want it to automatically "inherit" all of it's bases constructors. This kind of already happens today with the default constructor but I would like this extended to all constructors.

Here are a few code examples that show what I want to do.

//Simple base class with one parameter.
    public class Base {
        public Base(int IntParameter) {

        }
    }

//I have a derived class that can do more but takes the same constructors
//and simply passes them to the base class.  This is messy.
    public class DerivedV1 : Base {
        public void DoMore(){
        }
        public DerivedV1(int IntParameter) : base(IntParameter) {
        }
    }

//I can't do this today, but I want to.  In this case, it should get an automatic constructor:
//public DerivedV2(int IntParameter) : base(IntParameter) {
//}

    public class DerivedV2 : Base {
        public void DoMore(){
        }

    }

//Because I've specified a constructor, no constructor "propagation" occurs.
    public class DerivedV3 : Base {
        public DerivedV3(int IntParameter, string StringParameter) : base(IntParameter) {
            StringParameter.Equals(StringParameter);
        }
    }

In short, I want DerivedV2 to automatically "inherit" all of Base's constructors so that I don't have to litter my code with constructors that just pass values down the chain.

---

@HaloFour commented on Thu Jan 28 2016

For reference, this is the syntax that was added in C++11:

class Foo {
public:
    Foo(int x) { }
};

class Bar : Foo {
    using Foo::Foo; // inherit base constructors
};

...

Bar bar = Bar(123);

---

@alrz commented on Thu Jan 28 2016

What if I don't want to inherit every constructor? There should be some notation to specify exactly those ctors that you want to inherit, either in the base class or the derived class.

---

@MgSam commented on Thu Jan 28 2016

@alrz There is- exactly what you have today.

---

@alrz commented on Thu Jan 28 2016

@MgSam Yep, so this is just a matter of tooling I guess.

---

@bondsbw commented on Thu Jan 28 2016

@alrz If you want to remove a constructor from the set of inherited constructors, simply fall back to the existing syntax where you specify them all manually. Including any new constructor signature erases all constructor inheritance.

Otherwise if you just want to alter one constructor from that set, you can include that constructor with the same signature and the rest would inherit. (Not sure if that was the proposal but I'm suggesting it as a possibility.)

---

@alrz commented on Thu Jan 28 2016

---

@WrongBit commented on Wed Jul 06 2016

If you derive class from parent, isn't it your intention to repeat behaviour of base + add your own? If you wanna hide base constructors, why not to introduce special keyword? Example:

class Button {
    public Button(string ButtonText){}
}

class ButtonWithImage : **sealed** Button {
    public ButtonWithImage (Image img){}
}

Here we have ButtonWithImage, which should not have any text (that's why we should hide constructor). But by default constructor should be inherited and moreover - be callable by developer at any place of derived constructor (like it done in normal languages):

class Button {
    public Button(string ButtonText) {}
}

class ButtonWithImage : sealed Button {
    public ButtonWithImage (Image img){
        // some checks, actions
        inherited("simple text");// constructor is selected by signature
        // some more inits
    }
}

This way we have full control on what and where should be done. Theory shines only on paper, but in reality we need "dirty" way, because clean theory cannot cover real life.

---

@HaloFour commented on Wed Jul 06 2016

@WrongBit

If you derive class from parent, isn't it your intention to repeat behaviour of base + add your own?

Behavior, yes. Initialization, no. Not having constructors automatically inherited is very explicitly intentional on the part of most OOP languages as the nature of initialization is different for every class. It does not fit in the same category as virtual members.

C++11 and Groovy both added explicit syntax to opt-into constructor inheritance.

If you wanna hide base constructors, why not to introduce special keyword?

And automatically propagate the constructors without that keyword? That would represent a breaking change to the language, which makes it effectively a non-starter.

---

@HaloFour commented on Wed Jul 06 2016

This seems like it would be simple enough to solve with source generators:

public class Base {
    public Base(int x) { }
    public Base(int x, int y) { }
}

[InheritConstructors]
public partial class Derived : Base { }

// generates
public partial class Derived {
    public Derived(int x) : base(x) { }
    public Derived(int x, int y) : base(x, y) { }
}

[ghost]

Hope to see it done

[TahirAhmadov]

In addition to propagating constructors "as is", it would be very helpful to "extend" them, as well. I create a discussion for this: 5601.

class Base
{
  public Base(int x, int y) { ... }
}
class Child : Base
{
  public Child(int z) : base() { ... }
  // this actually becomes
  public Child(int x, int y, int z) : base(x, y) { ... }
}

I'm not sure what syntax to use here; I imagine this can be done with some new keyword, or using an existing contextual keyword, or some symbol. Basically, if the base class only has one "visible" (not private) constructor, we allow a child class to "extend" this constructor - and thus saving a lot of typing and maintenance.

[TonyValenti]

This wouldn't work because of the "magic" behind adding invisible parameters and then injecting them into the base.

In all honesty, while I still love the idea of constructor propagation, it might not be necessary once required properties are implemented.

[TahirAhmadov]

This wouldn't work because of the "magic" behind adding invisible parameters and then injecting them into the base.

Why do you think it's magic? The parameters will be visible to the caller, and if you mouse over the child constructor, IDE can show the full list of parameters.

In all honesty, while I still love the idea of constructor propagation, it might not be necessary once required properties are implemented.

While you may be right, I think this constructor extension approach is simpler. I had looked at the required properties proposal and seem to recall it became very complicated quickly. Also, since this is just syntax sugar, it will allow all the injection frameworks to continue working as if nothing happened. And IDE can just quickly refactor the old public C(int x, int y, int z) : base(x, y) { ... } to public C(int z) : base() { ... } (or whatever the syntax ends up being), thus making the code more readable.

[NN---]

You can use today source generators: https://www.nuget.org/packages/Constructor.Inheritor/

[TonyValenti]

AWESOME!!!

This should really be part of the language.

[cyraid]

It's 2025 and we still have to manually write out empty child class constructors that just call base? This really should be a part of the standard.

[CyrusNajmabadi]

we could have used other ways to have less code

There were no ways to accomplish those features with source generators.

The one feature I can think of that we could have done this with us records. And I still think that might have been a better way to go.

[cyraid]

@HaloFour then why not the team include this feature? Then one wouldn't need to include an external package they may not even have access to (or want) nuget, for a feature that makes sense and would save people a lot of time and effort.

Having to rely on that package from the community in every project of mine is a bit much no?

[HaloFour]

then why not the team include this feature?

Because none of them have found it compelling enough to support as a first class feature in the language?

[CyrusNajmabadi]

Having to rely on that package from the community in every project of mine is a bit much no?

No.

It's a minute of work that solves the problem.

have access to (or want) nuget

That's not something we design the language around. .Net is an ecosystem. You get the best out of it when you don't arbitrarily avoid using it. :-)

[CyrusNajmabadi]

then why not the team include this feature?

Because there is already a package that solves this. And if we spend our time working on this, then that means cutting the features we are working on that we think are much more important. :-)