Automatic Constructors

[TonyValenti]

TLDR:
When no constructors are defined, the compiler should automatically generate constructors whose signatures match that of the immediate base class. Today, this happens with only the default constructor but should be expanded to all constructors. To provide compatibility with existing code, in the event that a developer defines any constructors at all, the compiler will not generate any automatic constructors for that class.

Details:
Here is an example of the compiler generating an automatic constructor today:

    public class Base { }

    public class Derived : Base{
        //(nothing listed is the equivalent of the following)
        //public Derived() { }
        //OR public Derived() : base() { }
    }

This saves a lot of boiler plate code.

I would like to see this expanded to handle another scenario. For example, I often bump into scenarios like this:

public class Base {
        public Base(string Parameter) { }

        public Base(int Parameter) { }
    }

    public class Derived1 : Base{
        public Derived1(string Parameter) : base(Parameter) {
            //Nothing to do!
        }

        public Derived1(int Parameter) : base(Parameter) {
            //Nothing to do!
        }

    }

    public class Derived2 : Derived1 {
        public Derived2(string Parameter) : base(Parameter) {
            //Nothing to do!
        }

        public Derived2(int Parameter) : base(Parameter) {
            //Nothing to do!
        }
    }

You'll notice that in the examples above, the only reason I'm recreating those constructors is so that creating a derived class takes the same parameters as the base class. It is basically a bunch of filler.

I would like to be able to write the above code as follows:

    public class Base {
        public Base(string Parameter) { }

        public Base(int Parameter) { }

    }

    public class Derived1 : Base{
        //The following is created automatically:
        //public Derived1(string Parameter) : base(Parameter) { }
        //public Derived1(int Parameter) : base(Parameter) { }
    }

To provide compatibility with existing code, in the event that a developer defines any constructors at all, the compiler will not generate any automatic constructors for that class. For example:

    public class Base {
        public Base(string Parameter) { }
        public Base(int Parameter) { }
    }

    public class Derived1 : Base{
        //New Signature
        public Derived1() : base(0) { }

        //Required because I introduced the above constructor
        public Derived1(string Parameter) : base(Parameter) { }
        public Derived1(int Parameter) : base(Parameter) { }
    }

    public class Derived2 : Derived1 {
        //The following are generated automatically:
        //public Derived2() : base() { }
        //public Derived2(string Parameter) : base(Parameter) { }
        //public Derived2(int Parameter) : base(Parameter) { }
    }

[uygary]

I actually like the idea.
However, this is still a breaking change. We'll be silently introducing new constructors to classes that are already out there in the wild, and that could potentially cause issues, especially with code-bases that rely on reflection.

[TonyValenti]

@uygary - How would it be a breaking change? It would not generate new constructors that already exist because if any already exist, it will not generate any at all.

[HaloFour]

I'd rather an explicit syntax to specify that the constructors are delegated, like C++.

class A
{
    public: 
        explicit A(int x) {}
};

class B: public A
{
     using A::A;
};

[theunrepentantgeek]

@TonyValenti here's how it would be a breaking change. Imagine you have this code:

using System;
public interface ILogger { }

public class Base {
    private readonly ILogger _logger;
    public Base() { }
    public Base(ILogger logger)
    {
        _logger = logger;
    }
}

public class Derived : Base
{
}

At the moment the class Derived only has a single, parameter-less, constructor generated by the compiler. It may well have been deliberately written that way to ensure that it has exactly one constructor, due to use of reflection elsewhere in the project.

With your proposed change, Derived would automagically gain another constructor - one that accepts a logger, violating the project requirement for exactly one constructor.

[YairHalberstadt]

@theunrepentantgeek under reflection everything is a breaking change. As far as language features go, this one ranks pretty low on the breaking-change-o-meter.

[theunrepentantgeek]

I agree @YairHalberstadt - but was following up on @uygary's comment earlier to demonstrate the issue.

[uygary]

I generally agree that it would rank low as well. I'm just pointing out that it still is a breaking change, that's all.

[DjArt]

I have small addition for that idea - automatic constructors for readonly ref struct, that can provide compile-time constant value.

[WrongBit]

As a variant of proposal, we can introduce new syntax for inheriting:

class A : B // normal inheritance w/o constructors
class D :: E // inherit all constructors

Point is C# team should never apply "one of two" variants - it's stupid, it's unprofessional. If there is CHOICE of two GOOD PROPOSALS, you must offer BOTH variants. Like I offered above. Despite your experience, you can never know what business task we have. So we need choice.

[HaloFour]

@WrongBit

it's stupid, it's unprofessional.

The 👎 is for the unnecessary commentary. If your goal is to convince the team that they should be modifying the language to support this functionality calling anyone "stupid" or "unprofessional" is probably the fastest way to achieve the opposite.

The C# team has made it very clear that they don't add language features for the sake of offering choice. Every new feature adds complexity to the language and the compiler which then must be supported indefinitely. If you disagree with that to the point where you feel the need to denigrate the C# team, maybe this isn't the language for you.

[uygary]

@WrongBit I believe that's not such a good idea as it wouldn't align well with the existing syntax. It would be specific to ctors, whereas : works for both classes and interfaces. Maybe that's just me, so feel free to ignore me here, but it would look like a half-baked design to me.

As a side note, please refrain making remarks such as "it's stupid" unless you have links to some papers, that were published in peer-reviewed journals, which back that notion up.

If a language design team goes down the "Let's throw everything into the language!" path, they end up with a language like D. While I kind of like many features and innovations it has, I'm not so sure that they made the best choice by turning it into the "language that has it all, and in darkness binds them." It's far too large to learn and use, far too feature-rich to maintain, and far less consistent than it could've turned out to be.
Necessities of the language should be (and are actively being) discussed here in this forum, then weighed based on actual needs of the whole programming community, and then prioritized. There's nothing wrong with that, and in fact that's contributing to the consistency of the language design to a great extent.

I personally see and understand the need for this particular feature, and I like the idea. I hate boilerplate.
I'm just not sure this is the killer feature whose lack has been breaking my back at this point. And I certainly wouldn't want to end up with a syntax or feature-set the majority of the community would suffer in the long term.