Calling virtual method from base class ctor

[TahirAhmadov]

This is a known quirk of C#:

class Base
{
  public Base()
  { 
    this.Foo(); 
  }
  protected virtual void Foo() { }
}
class Child
{
  public Child():base()
  {
    this._str = "abc";
  }
  string _str;
  protected override void Foo() { Console.Write(this._str.Length);
}

This causes an NRE, despite compiling without any NRT warnings. I'm not sure if it's too late to fix now, but wanted to discuss anyway. Below is a possible solution to the problem.

class Base
{
  public Base() 
  {
    this.Foo(); // new warning: cannot call virtual methods before construction is complete
    after_constructed: // new keyword
    // code after this pseudo label is moved to a separate method which is called after most child ctor completes
    this.Foo(); // no warning
  }
  protected virtual void Foo() { }
}
class Child
{
  public Child():base()
  {
    this._str = "abc";
  }
  string _str;
  protected override void Foo() { Console.Write(this._str.Length);
}

In my proposal, another constructor is emitted, which is unspeakable, and accepts a new parameter of an enum type: option 1 - execute the "pre" code; option 2 - execute the "post" code; option 3 - execute both "pre" and "post" code.
If this parameter is option 1 or 3, the ctor code from beginning to that new pseudo-label is executed.
Then, if this parameter is option 2 or 3, the ctor code from the new pseudo-label to the end is executed.
The actual ctor just calls the unspeakable ctor with "full" option.
Child ctor: 1) calls Base unspeakable ctor with "pre" option, 2) executes its own body, 3) calls Base unspeakable ctor with "post" option.
Basically, the above compiles to:

class Base
{
  public Base() : this(CtorMode.Full) { }
  public Base(CtorMode ctorMode) // special un-speakable ctor
  {
    if(ctorMode.HasFlag(CtorMode.Pre))
    {
      this.Foo(); // "pre" code
    }
    if(ctorMode.HasFlag(CtorMode.Post))
    {
      this.Foo(); // "post" code
    }
  }
  protected virtual void Foo() { }
}
class Child
{
  public Child()
  {
    base(CtorMode.Pre); 
    this._str = "abc";
    base(CtorMode.Post);
  }
  string _str;
  protected override void Foo() { Console.Write(this._str.Length);
}
var b = new Base(); // this line just works

WRONG SOLUTION

In my proposal, the actual `Base` ctor consists of the code from beginning to that new pseudo-label. (Syntax is up for discussion.) Another method is also output, which consists of the code from the new pseudo-label to the end. `Child` ctor: 1) calls `Base` ctor, 2) executes its own body, 3) calls said `Base` "post-ctor" method. Basically, the above compiles to:

class Base
{
  public Base() 
  {
    this.Foo();
  }
  public void Base_PostCtor() // special un-speakable method
  {
    this.Foo();
  }
  protected virtual void Foo() { }
}
class Child
{
  public Child()
  {
    this.Base(); // call regular "ctor"
    this._str = "abc";
    this.Base_PostCtor(); // call the special method
  }
  string _str;
  protected override void Foo() { Console.Write(this._str.Length);
}
var b = new Base(); // this line also outputs:
b.Base_PostCtor();

[HaloFour]

This has been a known aspect of the design of the runtime since 1.0. It's discouraged to call a virtual method from the constructor.

What do you suggest that after_constructed does? The class isn't "constructed" until the constructor of the most-derived type is complete. There's no mechanism to return control back to the middle of one of the other constructors when that happens.

[TahirAhmadov]

I still think it's two decades too late to reconsider this.

Perhaps, but I think my proposal (I updated the OP with the unspeakable ctor approach) is backwards compatible and only "breaks" existing code which has the anti-pattern of calling virtual methods from constructors. If we had this conversation 20 years ago, then we could've built something like this into the runtime, but I think my proposal is not far off from the "ideal" solution (had it been done 20 years ago).

Calling virtual methods from a constructor has always been an antipattern, we shouldn't be solving to make it less of one.

And that's the idea: we're taking an anti-pattern and making it a warning (which, granted, is a breaking change), but also offering a way to accomplish it in a safe manner.

[HaloFour]

I think it creates a worse problem. With two phase initialization a derived constructor can never be confident as to the state of the fields of the base type.

[TahirAhmadov]

I think it creates a worse problem. With two phase initialization a derived constructor can never be confident as to the state of the fields of the base type.

Good point; I'll think about how to deal with it.
My initial reaction would be, even today the derived constructor can not really be confident - base constructor can do or not do anything and there is no control over it. In this future two-phase world, it would be incumbent on the developers to make sure they're aware of this behavior and set fields accordingly.

[HaloFour]

Sounds like a bigger trap than simply knowing to not call virtual methods from a constructor.

[TahirAhmadov]

In my case, I need to do it, unfortunately - the only other option being, invoking another method post-construction (which is what I'm doing) but it introduces its own problems - namely, I have to follow the convention of calling said method, etc.

[RikkiGibson]

Nullable constructor analysis doesn't stop you from accessing any members, virtual or non-virtual, before all the fields are in the expected state (i.e. construction is "complete".)

There is an official analyzer to warn users away from accessing virtual members from constructors. https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2214

[TahirAhmadov]

Nullable constructor analysis doesn't stop you from accessing any members, virtual or non-virtual, before all the fields are in the expected state (i.e. construction is "complete".)

The NRT aspect of this is not as important - it was just a demonstration of the underlying issue.

There is an official analyzer to warn users away from accessing virtual members from constructors. https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2214

Good to know, thanks.

Any thoughts about my proposed way of making it possible without the downsides?

[RikkiGibson]

I think that if an initialization scheme this complex is needed, then I'm OK with the user needing a factory method. e.g.

class Derived : Base
{
    public Derived Create()
    {
        var derived = new Derived();
        Base.PostInitialize(derived);  // relies on virtual methods on 'Base' being well-behaved when called on 'derived'
        return derived;
    }
}

[TahirAhmadov]

Factory methods are not friendly with init-blocks; I'm trying to construct a control tree, set all of the properties, etc.

[Joe4evr]

This might be solved if the "validator"-method would ever be added.

[TahirAhmadov]

That is very interesting. I like the validator method feature both for its intended purpose - validation - and also any post-construction initialization that may be needed. I think it should support calling base class validator methods - question being, is it mandated, or optional like with ctors?

[Joe4evr]

and also any post-construction initialization that may be needed.

Yeah, that's why "validator" is a bit of a misnomer, but it's the best suggestion at the moment without getting overly verbose. But it's not only about validation, the stuff you're describing is also very much an intended role. ("Initialization Finalizer" certainly sounds more accurate, but 1: is a mouthful, and 2: sounds like an oxymoron.)

I think it should support calling base class validator methods

Tbh, I'm not certain that validators will be manually callable, and I very much believe that's how it should be done (reflection notwithstanding). Beyond that, it'll be up to the language team to determine the behavior of validators on multiple participants in a type hierarchy (because I don't have a clue what's most sensible), but the easy thing for lib authors would be to just declare the validator on their Base class which calls into a regular protected virtual method since letting derived types override that is already well-defined and understood behavior.

question being, is it mandated, or optional like with ctors?

Mandatory how? If you don't declare a validator method, that type doesn't have a validator method. It's not rocket science.

[TahirAhmadov]

"Completer" maybe?
My question WRT to "validators" on multiple classes is motivated by the serious implications - if Student inherits from Person, and for whatever reason a rule of Person doesn't apply to Student, then there is no way to "escape" that (if we mandate that all validators up and down the class hierarchy are called). But maybe, it's an anti-pattern to "lift" inherited validation rules?
The virtual method approach works if you control the base class, but if you don't and that author chose not to use one, and just placed the code into the validator itself, you can't opt not to call the base. Similarly for simply not defining the validator - if you don't control the base class, you're stuck with its validator - if it has one.

[TahirAhmadov]

Another thought: why not just make it a virtual method, which cannot be called directly, but behaves like a virtual method in every other way?

[Joe4evr]

if Student inherits from Person, and for whatever reason a rule of Person doesn't apply to Student, then there is no way to "escape" that (if we mandate that all validators up and down the class hierarchy are called). But maybe, it's an anti-pattern to "lift" inherited validation rules?

That is most certainly an anti-pattern since it breaks the principle of Liskov substitution (specifically Postconditions cannot be weakened in the subtype and the state of an object's fields after construction is a postcondition), so prohibiting this anti-pattern is a good thing.

In the scenario you put forth Student shouldn't inherit Person to begin with, but be an independent type with independent pres/posts/invariants. Inheritance is not meant to only be a lazy shortcut to reduce redeclaring the same members.

Another thought: why not just make it a virtual method, which cannot be called directly, but behaves like a virtual method in every other way?

That'd work, actually. I'd imagine the compiler would then implicitly insert a call to the base validator (if it sees one), because of the Liskov reasons.

[iPilot]

Have you ever thought about a replacement of the get keyword (like init replaces set) for abstract/virtual properties?
I could be expr keyword that limits a property to be an expression-bodied preventing it from being initialized in derived class constructor.
And also there could be a stricter version of such keyword like const expr that should prevent base class from using class members at all.
Such keywords can also give some additional information about class properties on surface analysis i.e. if the value returned by property could change or not on class state changes.

[ufcpp]

class Base
{
    public Base()
    {
        this.Foo();
    }
    protected virtual void Foo() { }
}
class Child : Base
{
    string _str = "abc"; // Field initializers are executed before the base constructor
    protected override void Foo()
    {
        Console.Write(this._str.Length);
    }
}