Required constructors in derived abstract classes

[bzd3y]

How feasible is it to not require abstract classes derived from another class to (re)implement a trivial non-default constructor? This would be similar, conceptually, to how abstract properties are handled.

Consider the following:

public abstract class SomeClassA // I suppose it doesn't really matter if this is abstract
{
    public SomeClassA(int x, int y, int z)
    {

    }
}

public abstract class SomeClassB : SomeClassA // being abstract matters here
{
    // this produces: error CS7036: There is no argument given that corresponds to the required parameter 'x' of 'SomeClassA.SomeClassA(int, int, int)' or if there are multiple base constructors then the error is about there being no parameterless constructor.
}

public abstract class SomeClassC : SomeClassA // being abstract matters here
{
    public SomeClassC(int x, int y, int z) : base(x, y, z) // this is required even though the class is abstract and cannot be constructed
    {

    }
}

So SomeClassB causes a compiler error like "error CS7036: There is no argument given that corresponds to the required parameter 'x' of 'SomeClassA.SomeClassA(int, int, int)'".

But any concrete (or currently abstract) class that inherits from SomeClassB has to implement a constructor that calls one from SomeClassA. So why does SomeClassB have to, especially when it can't actually be constructed?

Two approaches I could think of are:

1. SomeClassB has no SomeClassB.ctor() at all (when the developer omits it, of course), and the compiler would just "follow" the base classes like I'd imagine it already has to do in order to get everything it needs (like any less-derived abstract properties).
2. If the constructor is omitted, just have the compiler emit the equivalent IL or whatever is needed at whatever stage this would be done. As far as I can tell this would just be nearly identical to SomeClassA.ctor() (though I don't know if/how easy it is for the compiler to use that if that class is in another assembly) except that it would call SomeClassA.ctor() instead of Object.ctor().

I don't know enough to know which is ideal. Option 1 certainly seems possible, since the compiler already "skips" classes to get things like abstract properties that are required, and I guess default constructors. But Option 2 might be preferrable for the explicit IL and/or for backwards compatibility with things that might expect the IL to be there.

Obviously, if the developer adds a constructor then the compiler would just do what it currently does.

[huoyaoyuan]

Because every derived type must call its base type's constructor, not other ancestor type. The constructor of abstract class logically initializes every state at this level. For example, if you have a field with default value, it's initialized in the constructor:

public abstract class Ancestor
{
    public Ancestor(int unused) {}
}

public abstract class Base : Ancestor
{
    private int state = 123;
    public Base(int unused) : base(unused) {}
}

Here the constructor of Base actually contains the initialization of state. It's a totally different, unrelated method than constructor of Ancestor.

Properties are methods exposed to callers, not state kept by implementers.

[huoyaoyuan]

For implicit propagation of constructor with the same signature, see #806.

[bzd3y]

Those aren't trivial constructors though. Base.ctor() has code in it. I'm talking about when there is no code and all that is happening is that parameters are being forwarded.

And that other discussion is interesting, but it also doesn't really apply here. They are talking about a lot more than what I am talking about.

All I'm talking about is not requiring abstract types that cannot be constructed and have no constructor to have to define one.

The compiler should be able to handle this easily in at least one of two ways, as I pointed out (could even be configurable/attributable).

[CyrusNajmabadi]

We're not comfortable synthesizing public surface area like this for a type. You could always write your own source generator to produce these for you if you want.

[HaloFour]

And that other discussion is interesting, but it also doesn't really apply here. They are talking about a lot more than what I am talking about.

The goal is the same, though, an explicit syntax which indicates to the compiler to emit a default constructor that forwards the parameter values to the base constructor. That is exactly what you're asking to accomplish here.

[bzd3y]

@CyrusNajmabadi Understood, but at the same time, is it really a public surface area? You can never actually access that constructor in code, right? (other than from another constructor) Very often they are protected anyway. And I don't think anything has to be synthesized (depending on what you mean by that). It seems like the compiler could just "skip" the abstract classes that don't implement a trivial constructor and instead of calling a constructor on them, call the constructor "below" them.

@HaloFour Not to sound argumentative, but no, it really isn't. Maybe my goal is a small implicit part of their goal. But my goal is really just to eliminate having to write redundant, trivial code. Of course, the IDE can do that for me, so it isn't really a matter of it being a pain or inconvenient. It's more just cleaner/less code and the fact that you look at this class and wonder why it has a constructor at all, because it cannot actually be constructed and the constructor it has does nothing.

[CyrusNajmabadi]

Understood, but at the same time, is it really a public surface area?

Yes.

You can never actually access that constructor in code, right? (other than from another constructor)

Yes. From another constructor. Not sure why that changes anything. :-)

because it cannot actually be constructed and the constructor it has does nothing.

It can be constructed. Just not through a direct 'new' call of the abstract type. It's how the derived type gets constructed.
It's also the abi for the type.

The idea is that you, as the derived type, do not know what the base constructor is doing. It's just a function call. It could do nothing but forward arguments along. Or it could do anything else. And that can change at any time.

If the derived type could just call through to the grandparent, then the parent could change/add a constructor and the derived type would be breaking the contract here.

Remember, types commonly live across assemblies. And dependent assemblies are commonly not rebuilt when an antecedent assembly is changed.

[CyrusNajmabadi]

and wonder why it has a constructor at all,

The constructor is the type stating: here's how you make me.

Even if that logic is trivial in your mind (just forwarding arguments along), that's part of the contract it provides to subclasses.

Again though, if you think it's cleaner to not have this. Just write an SG to generate it for you. :-)