Defer constructor

[Thaina]

To allow initialization able to call abstract member. I think we should have some syntax to allow defer initialization of constructor

public abstract class A
{
    public abstract string Name { get; }
    public SomeThing Value;
    public A()
    {
        Console.WriteLine("A");
    }
    defer
    {
        Console.WriteLine("defer A");
        if(!dictionary.TryGetValue(Name,out Value)) // can call abstract property Name
            dictionary[Name] = Value = new SomeThing(Name);
    }
}

public class B : A
{
    public override string Name => name;
    public readonly string name;
    public B(string _name)
    {
        Console.WriteLine("B");
         name = "uniqueString" + _name;
    }
    defer
    {
         Console.WriteLine("defer B");
    }
}

////////////////////////////////////////////////////////////////

new B("TT");
// A
// B
// defer B
// defer A

The defer block will be called like a stack. Normal constructor would be called from base to derived. But after finished construction it would invoke defer constructor from the derived back to base. And so the each of the base class can call derived class overridden member here

With this feature we would not need any initialization framework and can use only new to orchestrate complex initialization

[djblack]

Hi,

I like this idea, I often find myself needing an Initialize() method which is called from the most derived class. However the problem with this is that it precludes deriving another class.

Although I think I would prefer to call the defer constructor bottom up in a similar way to the constructor(or allow the user to specify where the base is called).

Is there a better way to handle this problem?

David

[canton7]

Alternatively, allow the base ctor to be explicitly called at any point in the ctor, as in ruby:

public abstract class A
{
    public abstract string Name { get; }
    public SomeThing Value;
    public A()
    {
        if(!dictionary.TryGetValue(Name,out Value)) // can call abstract property Name
            dictionary[Name] = Value = new SomeThing(Name);
    }
}

public class B : A
{
    public override string Name => name;
    public readonly string name;
    public B(string _name)
    {
         name = "uniqueString" + _name;
         base();
    }
}

Although I'm not too fond of that either, at least it's a little easier to reason about.

[yaakov-h]

I don't think it's neccesary to create a new language construct to enable/support blatant violations of CA2214.

It would be nice if we could do work before calling the base constructor (as @canton7 illustrated whilst I'm typing this), which IMO would be a vastly more readable approach and require no new syntax nodes.

[djblack]

Hi,

Not sure I understand what makes two stage initialization problematic? I can see how mixing the two stages would be confusing and error prone though.

David

[Thaina]

@canton7 I have seen that in some issue and I think that was actually dangerous. It cannot guaranteed that the derived will ever call the base at all. And it also cannot guarantee that the descendant would not try to look at the member of the base class before calling base

And so I completely disagree to any of Do work before calling base. It should be clear that in the constructor step, base class shouldn't ever expect derived class on anything. And my defer proposal is just that it will invoked as event just after the construction is actually finished

The point is we just actually need a complete initialization at the constructor. And that just involve allowing base class to access the derived class implementation. Which could be done with abstract or virtual. And so we actually need stack traversal. Top to bottom then return from bottom back to top. Like OnBefore- and OnAfter-. I think that should be what we all need for construction logic

[canton7]

It cannot guaranteed that the derived will ever call the base at all

Obviously for backwards compatibility, you will need to implicitly call base() if it wasn't explicitly called. I don't like the fact that sometimes calling base() will be implicit and sometimes explicit, but "It cannot guaranteed that the derived will ever call the base at all" cannot ever be true.

Your proposal is just splitting the constructor into two parts. Part of the derived class's constructor will be called before part of the base class's constructor (that is after all the entire point of this proposal). This also does "Do work before calling base" -- you've just fudged the problem by calling part of base's constructor "defer" -- but it's still effectively part of the constructor.

If you disagree with the semantics of my syntax, then by implication you're disagreeing with your own proposal 🤷‍♂

---

I still agree with @yaakov-h in that we shouldn't be adding syntax which encourages people to violate common-sense rules.

If you really need this behaviour, you can do it already (although it's a tiny bit ugly):

public abstract class A
{
    public abstract string Name { get; }
    public SomeThing Value;
    public A(string _name)
    {
        Initialize(_name);
        if(!dictionary.TryGetValue(Name,out Value)) // can call abstract property Name
            dictionary[Name] = Value = new SomeThing(Name);
    }
    protected abstract void Initialize(string _name);
}

public class B : A
{
    public override string Name => name;
    private string name;
    public B(string _name) : base(_name)
    {
    }

    protected override void Initialize(string _name) => name = "uniqueString" + _name;
}

[Thaina]

This also does "Do work before calling base"

This is not. That's why I propose this feature

Because the base will always must be call the before part before the derive. It just have a defer part that not actually a constructor. It just a promise to call after constructor was finished. So actually there are no code in the derived class that will be ever called before base class constructor. That is the point of this proposal. I was actually try to avoid that Do work before calling base to happen

And the rule is still exactly the same. You can't call abstract or virtual member before the derived class are finished construction. It actually your proposal to Do work before calling base that actually totally violate this rule, not mine

ps. I don't understand what are you trying to do with that code? You can't call Initialize in A because it is abstract

[canton7]

It just have a defer part that not actually a constructor

You can call it what you want, but it is still effectively part of the constructor, as it's called as part of the construction process.

If you want to make it explicitly not part of the constructor, then do this -- you don't need any special syntax:

public abstract class A
{
    public abstract string Name { get; }
    public SomeThing Value;

    protected void Initialize()
    {
        if(!dictionary.TryGetValue(Name,out Value)) // can call abstract property Name
            dictionary[Name] = Value = new SomeThing(Name);
    }
}

public class B : A
{
    public override string Name => name;
    private string name;
    public B(string _name)
    {
        name = "uniqueString" + _name;
        Initialize();
    }
}

[Thaina]

@canton7 No it's not

public abstract class A
{
    public abstract string Name { get; }
    public SomeThing Value;

    protected void Initialize()
    {
        if(!dictionary.TryGetValue(Name,out Value)) // can call abstract property Name
            dictionary[Name] = Value = new SomeThing(Name);
    }
}

public class B : A
{
    public override string Name => name;
    private string name;
    public B(string _name)
    {
        name = "uniqueString" + _name;
        Initialize();
    }
}

public class C : B
{
    public override string Name => "CString" + base.Name;
    public C(string _name) : base(_name) { }
}

////

new C("TT"); // Initialize will not call C.Name because it call in constructor of B, not in C and C are not finish construction yet

And also your hack is already what I have did before writing this issue. Which is also cannot guarantee that the derived class will ever call base.Initialize()

[canton7]

Did you try your own code? DotNetFiddle.

Which is also cannot guarantee that the derived class will ever call base.Initialize()

There are lots of things you can't guarantee. There are many things a programmer can do which will break things. You could set a flag in the base class when it's initialised, and check that before other methods are called, the same as setting a flag when Dispose() is called.

You could also easily write an analyzer which checks whether Initialize has been called. You could get that working in a matter of days, rather than waiting a matter of years for a proposal like this to be implemented.

[djblack]

@canton7 while swapping the functionality of the constructor and second phase works, it is even more difficult to see what is going on...

[canton7]

@canton7 while swapping the functionality of the constructor and second phase works, it is even more difficult to see what is going on...

I'd argue it's about the same level of difficulty. Bear in mind that the OP's suggestion means learning entirely new syntax and remembering how it works (which isn't an easy thing to conceptualise). Syntax like this would be used incredibly rarely, so for most people seeing it they probably won't have seen it before. My suggestion at least uses syntax which already exists and which people are familiar with.

[Thaina]

@canton7

There are lots of things you can't guarantee.

We have a language and compiler to make something could be guarantee man

Did you try your own code? DotNetFiddle.

If this is already work then it actually should be bug. It means that we actually finished overriding member from the derived class even before it call the constructor of derived class. Which should not happen. This is the actual totally violation of CA2214

[canton7]

If this is already work then it actually should be bug.

I think you have a gross misunderstanding of how that code works. C's constructor does not do anything except call B's constructor.

You've overridden "Name" to mean "CString" + base.Name;. You've effectively defined a method which returns "CString" + base.Name; every time it is called. That doesn't need to be set up from C's constructor - it's just an intrinsic part of C. Try walking through your code in a debugger.

[Thaina]

@canton7

C's constructor does not do anything except call B's constructor.

If this sentence is true then we should not have CA2214 at all from the start. We should always have virtual function be called in the constructor directly. Which is not true

It's not about C# constructor do any more works, it is the order of operation. Constructor should be called along with other member inline assigning. That's include overriding the abstract and virtual and overridden member. And so if it still calling base class constructor, the derived class should not have initial anythings yet, that's why we can't call abstract member yet because it didn't override at the time of base class's constructor and that's the reason of CA2214

[Thaina]

@HaloFour Sorry if it make you felt bad but I don't intend to insulting. What I said is meant, to think that we should refactoring the constructor to make a static method or factory is the problem

[Thaina]

@HaloFour

We don't expect constructors to initiate expensive fallible logic

I think I have seen some people already want async constructor. And I have seen you have reply in some issue that; "we should have some syntax to run some code before calling base constructor, to validate argument" or something like that

At first I don't think that constructor should do anything much too. But after some thought I realize that, constructor is always be the first method everyone think about create any object in the code. If the API provider require that object should be completely initialized by any means, the language should allow them to orchestrate constructor for it. Or the language should deprecated constructor and promote some other means of creation. So every class would have the same single entrypoint

I think the design of class like SQLConnection is not related to this. It was design that way because we can Disconnect and Reconnect so the act of connection was separated from constructor. Also there was an api design that make a connection object and disconnect by dispose it too, that way the constructor itself also be the connection

[Thaina]

@HaloFour And also another problem of both the static create method and factory is, it cannot reflect the constructor of derived class

It can't even specify constructor pattern, even if it can (which there was propose for such times as #769 but not much movement) it still restrict that every derived class must implement the same constructor. It then force derived class to not able having new argument it might wanted to. And if you refactor it to be empty constructor and Init method, then it cannot set any readonly field from constructor argument (my defer proposal still don't allow setting a readonly field in defer block, but it still able to set readonly field in normal constructor block)

If you thought we should just refactoring everything with pattern then it just like we craft everything with PVC and duct tape. Sure you can make anything this way but it's ugly

[Thaina]

@HaloFour @canton7 Tuple syntax also cause compiler error in older version too. And I don't see anyone in corefx have any problem with that

And we also could solve the tuple problem can't be used in older version by include ValueTuple package

Then how about we make those code injection as package for older version too is it possible??

[canton7]

@Thaina NuGet packages can provide types. They can't cause older compiler versions to learn how to compile things differently.

Tuples are different - we use a NuGet package so that you can use tuples with a new compiler but an old framework. The NuGet package doesn't let you use tuples with an old compiler.

[Thaina]

@canton7 I think code analysis and injection or ILManipulation on post build can made into package isn't it?

doesn't let you use tuples with an old compiler.

Then this feature could be the same

[canton7]

@Thaina Think about it. If you've got a base class compiled with a new compiler and you're compiling a derived class with an old compiler, either the old compiler throws an error, in which case there's no assembly for your post build IL rewriter to rewrite, or the old compiler does not throw an error (and just doesn't call defer), and there's no indication that people need to install your magic NuGet package.

[YairHalberstadt]

@canton7

You could use an obsolete attribute to tell people to use the nuget package, and then suppress the error manually. In theory.

[Thaina]

@canton7 I think it just that; If we could made a package for magic compiler extension then we need to have using some type in the same assembly as that magic compiler to make it error that it missing the type from some package (maybe attribute to mark that defer block as a function), so people would go grab that package, which also include the attribute and the code injector

And if it could not then just make it error in old compiler

Anyway I think it would always be the same as how we handle Tuple

[yaakov-h]

With Tuples, the compiler knew exactly how to deal with the syntax, but was missing the underlying core types. Those types could be supplied by a variety of means including the BCL, user code, or referenced assemblies such as a nuget package.

You cannot use a nuget package to fix a binary compatibility breaking change that would be introduced by a new language feature that is inherently incompatible with the calling convention of the old compiler.

(Well, you could use Microsoft.Net.Compilers, but nobody on the language team or corefx is going to accept that as a solution.)

[canton7]

@Thaina

then we need to have using some type in the same assembly as that magic compiler to make it error that it missing the type from some package (maybe attribute to mark that defer block as a function)

It's perfectly legal to reference a type in a different assembly, where that type references some other type which you don't know about, I think? That won't cause the old compiler to error.

It's worse than that, though. Let's assume that you've put a new attribute on your defer constructor in the base class. Now in order for the new compiler to compile that base class, the new attribute has to be defined somewhere. Maybe it's injected by the new compiler, or maybe it's added to a new version of the BCL. Either way, the old compiler can still access it!

[Thaina]

@canton7 If it in new version of BCL then shouldn't it be a new compiler?

And if it was old compiler, you shouldn't be able to use BCL, so you need to import the assembly from nuget isn't it?

[HaloFour]

IMO this proposal could not emit normal constructors. That's what gets it into trouble with downlevel compilers. Instead, if it were to emit static methods and then treat those methods as constructors you could solve the problem of using the feature from downlevel compilers as well as other languages.

// given:
public class Foo {
    public Foo(string s) {
        Console.WriteLine("Hello");
    } defer {
        Console.WriteLine("World");
    }
}

// the compiler emits:
public class Foo {
    private Foo(string s) {
        Console.WriteLine("Hello");
    }

    public static Func<Foo> Create(string s) {
        var foo = new Foo(s);
        return () => {
            Console.WriteLine("World!");
            return foo;
        };
    }
}

To updated compilers this could look like a normal constructor:

Foo foo = new Foo("bar");

But to downlevel compilers they would have to call the static method directly:

// broken into two lines to show detail
Func<Foo> initializer = Foo.Create("bar");
Foo foo = initializer();

I still don't endorse the idea, but this should at least address most of the issues I have with the implementation and avoids the biggest issue which is that by reusing constructors other compilers would silently do the wrong thing.

[canton7]

@HaloFour that private ctor won't work if there's a derived class (which, after all, is the point of this feature).

Once you make the constructor protected, there's nothing to stop a derived class (compiled with a downlevel compiler) from exposing it as public.

[Nevynette]

The Delphi language introduced a method called AfterConstruction() (IIRC) that would automagically be called after all the constructors in the hierarchy are executed. It was a fertile source of bugs.

It was the combination of overriding TObject.AfterConstruction() and tossing in the inherited keyword in the middle of constructors that made for interesting marathon debug sessions. Not to mention that static (class) methods can be overridden in Delphi and NewInstance() is both public and virtual.

What could possibly go wrong with that?