Allow calling base class constructor in the middle of derived class constructor

[munael]

To allow

class Derived : Base {
    Derived(Foo foo) {
        // do bar and baz with foo
        base(bar, baz);
        //  blah
    }
}

Instead of having to extract the do bar and baz section into static functions (one for each argument in the base constructor that needs modified values). If we can already functionally do this, there should be no need for the extra complication.

Any standing theoretical reasons for the restriction?

[HaloFour]

@narfanar

Any standing reasons for the restriction?

It's easier to comprehend that you're very limited as to what you can do before the base constructor call when the syntax forces it on you. Yes, you can make your code slightly less verbose by eliminating the need for a separate function, but it's a suitable workaround for what is not a terribly common situation.

[CyrusNajmabadi]

Any standing reasons for the restriction?

Yes, the language doesn't allow it.

As for why it doesn't allow it, the general reason is around the complexity of the programming model, especially around initialization, virtual-calls, and whatnot.

[HaloFour]

@CyrusNajmabadi

As for why it doesn't allow it, the general reason is around the complexity of the programming model, especially around initialization, virtual-calls, and whatnot.

I get the sense from the question that they're not looking to ease the restrictions, only allow the restricted code to exist before the base constructor call.

[munael]

@narfanar

Any standing reasons for the restriction?

It's easier to comprehend that you're very limited as to what you can do before the base constructor call when the syntax forces it on you. Yes, you can make your code slightly less verbose by eliminating the need for a separate function, but it's a suitable workaround for what is not a terribly common situation.

The verbosity (and even wasted work) rapidly spiral out of control once several arguments of the base class constructor need to be themselves prepared from the arguments of the derived class constructor.

Verbosity because then we need separate static functions (and calls) to get the value of each argument passed to the base constructor, and wasted work if it happens that several such arguments can share parts of their preparation functions.

D allows this. I remember there were issues with virtual functions and some order of construction stuff. Will see if there're salient lessons there that could help the case of this issue.

[voroninp]

IL also allows it, btw.

public class Foo
{
	public Foo(int i)
	{		
	}
}

public class Bar: Foo
{
	public Bar(string s):base(int.Parse(s))
	{		
	}
}

And here's how Bar constructor looks like:

.method public hidebysig specialname rtspecialname 
	instance void .ctor (
		string s
	) cil managed 
{
	.custom instance void System.Runtime.CompilerServices.NullableContextAttribute::.ctor(uint8) = (
		01 00 01 00 00
	)
	// Method begins at RVA 0x2153
	// Header size: 1
	// Code size: 15 (0xf)
	.maxstack 8

	// {
	IL_0000: ldarg.0
	IL_0001: ldarg.1
	IL_0002: call int32 [System.Runtime]System.Int32::Parse(string)
	// (no C# code)
	IL_0007: call instance void UserQuery/Foo::.ctor(int32)
	IL_000c: nop
	// }
	IL_000d: nop
	IL_000e: ret
} // end of method Bar::.ctor

So yes, C# should also allow this:

public Bar(string x, string y)
{
    var xi = int.Parse(x);
    var yi = int.Parse(y);
    base(xi+yi);
}
}

[YairHalberstadt]

and wasted work if it happens that several such arguments can share parts of their preparation functions.

Whilst a hacky workaround, you could use out parameters to avoid this wasted work.

[dsaf]

@narfanar

Any standing theoretical reasons for the restriction?

https://en.wikipedia.org/wiki/Halting_problem

[munael]

@YairHalberstadt

How would you out into the arguments of the base constructor? Can you provide an example?

@dsaf

@narfanar

Any standing theoretical reasons for the restriction?

https://en.wikipedia.org/wiki/Halting_problem

Sorry? I'm not following.

[YairHalberstadt]

Public class A
{
    public A(int a, int b) {}
}
Public class B : A
{
    public B(string str) : base(GetBaseParams(str out int b), b){}
    public int GetBaseParams (string str, out int b)
    {
         strs = string.Split(str);
         b = int.Parse(strs[1]);
         return int.Parse(strs[0]);
    }
}

[yahoo0742]

@YairHalberstadt If the GetBaseParams is static from your example, I'd support it. Otherwise I prefer the to receive a warning.

[yaakov-h]

@Korporal and then Cyrus addresses the reasons in literally the next line. Personal attacks are not appreciated here.

[HaloFour]

I'm kind of on the fence about this. I have written classes that had to manipulate/validate parameters before passing them along to a base constructor before, pre-C# 7.0, and it was painful as all Heck. With out parameters it's considerably less painful since you can pass the arguments along to a static method that does the work and passes them back, but that's still not exactly pleasant and it moves the initialization code far away from where it's relevant. It seems that it should be safe to allow arbitrary statements before base(...) as long as this is inaccessible (including all instance members). IIRC that's what the CLR allows, it's just that the current C# syntax doesn't allow anywhere to put those statements.

There could be two ways of accomplishing this syntax-wise. You could have a block before the base constructor call:

private readonly int y;

public Derived(string x, int y) {
    // static stuff here only
    if (string.IsNullOrEmpty(x)) throw ArgumentException();
} : base(x) {
    // can access instance members here
    this.y = y;
}

Or allow base to appear like a method call within the constructor body:

private readonly int y;

public Derived(string x, int y) {
    // static stuff here only
    if (string.IsNullOrEmpty(x)) throw ArgumentException();
    base(x);
    // can access instance members here
    this.y = y;
}

The first trades some verbosity for very clear delineation of the sections of code.

[YairHalberstadt]

I'm leaning towards the first option, but http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html?m=1

[theunrepentantgeek]

I cut my teeth as a professional developer using Delphi - and its Object Pascal explicitly allowed/required a call to the base constructor as a regular statement.

It was common to find subtle object initialization bugs where certain instance methods would only work after the base constructor call. Sometimes, when we were lucky, they'd throw. Other times, they'd return incorrect or inconsistent results.

I vividly remember having to untangle some chicken-and-egg scenarios where function Foo() would only give correct results after the base constructor was called, but the result of Foo() was needed to make that call.

[CyrusNajmabadi]

Another vacuous reply from Cyrus!

I literally explained why in the post you snipped from and didn't quote fully. The language doesn't allow this because of "the general reason [...] around the complexity of the programming model, especially around initialization, virtual-calls, and whatnot."

That is truthful and accurate and appropriate given the question.

[The-Futurist]

@CyrusNajmabadi

Another vacuous reply from Cyrus!

I literally explained why in the post you snipped from and didn't quote fully. The language doesn't allow this because of "the general reason [...] around the complexity of the programming model, especially around initialization, virtual-calls, and whatnot."

That is truthful and accurate and appropriate given the question.

Well Cyrus I'm afraid I've found you to be somewhat supercilious in many of your exchanges, a person asks "Any standing reasons for the restriction?" and you simply cannot resist trying to appear erudite by responding "Yes, the language doesn't allow it." which is a tautology.

Most of us would have omitted that and simply said the second part of your response. You must understand that the tone and character one uses in these posts is an important aspect of communication be it technical or otherwise, I simply think you need some work in this area.

[HaloFour]

@theunrepentantgeek

I don't know about the modern versions, but Delphi supported this at least in versions 1-7 of its Object Pascal language. IIRC, the compiler enforced that exactly one inherited constructor call was made.

Looks like that's still the case with Oxygene:

https://docs.elementscompiler.com/Oxygene/Members/Constructors/

[yaakov-h]

Here's a real-world use-case I came across just last week:

using System;

namespace MyLibrary
{
    public partial interface IRuleInfo
    {
        public Guid Id { get; }
    }

    [Serializable]
    public class RuleValidationException : Exception
    {
        public RuleValidationException(IRuleInfo ruleInfo, Exception inner)
            : base(GenerateMessage(ruleInfo), inner)
        {
        }

        /* Additional constructors omitted */

        static string GenerateMessage(IRuleInfo ruleInfo = null)
        {
            return ruleInfo == null ? "Rule validation failed" : "Rule validation failed for Rule id: " + ruleInfo.Id;
        }
    }
}

It would be a lot nicer and easier to read if I could use the following constructor instead:

public RuleValidationException(IRuleInfo ruleInfo, Exception inner)
{
    if (ruleInfo == null)
    {
        base("Rule validation failed.", inner);
    }
    else
    {
        base("Rule validation failed for Rule id: " + ruleInfo.Id, inner);
    }
}

[juliusfriedman]

@yaakov-h, I👏your efforts but find your first example better as it encapsulates OOP.

You can return an exception from a Validate method and not throw it too but that's rather heavy... why not just have a Validate which returns a State perhaps with a dictionary or otherwise...

The example you provided cannot be overcome by the base class changing the constructor which it calls and or another exception being thrown from that constructor anyway.

Also you can't really even guarantee that your constructor won't encounter the oom due to base classes logic so a Validate or Initialize method will beat this hands down evrtytime and doesnt require the effort to implement nor provide the issues which this may especially for structs.

[HaloFour]

@juliusfriedman

find your first example better as it encapsulates OOP.

What does that have to do with OOP? That's like arguing that you can never override a member unless the very first thing you do in the overridden method is to call the base method. The fact that you can do other things before invoking the base method doesn't break anything about OOP. Heck, the fact that you're allowed to invoke the base method zero times, or a thousand times, doesn't break OOP. There's no tenet of OOP that requires that a base constructor call be the first "statement".

The example you provided cannot be overcome by the base class changing the constructor which it calls and or another exception being thrown from that constructor anyway.

That doesn't make sense. The derived class calls the base constructor in this example. If the base class was changed in that the constructor was no longer compatible that would break all code consuming the base class, irrespective of this proposal.

Also you can't really even guarantee that your constructor won't encounter the oom due to base classes logic so a Validate or Initialize method will beat this hands down evrtytime and doesnt require the effort to implement nor provide the issues which this may especially for structs.

Nobody is asking for such a guarantee. Nothing can guarantee that a field initializer won't throw, or that a static method called by the derived constructor within the base constructor call won't throw. Forcing the developer to move otherwise local validation and calculation code doesn't change any of that equation at all, except to break code locality and force additional boilerplate.

[juliusfriedman]

@HaloFour

constructor which it calls, is what I said, all objects call a base constructor either ValueType or object or otherwise as required by the CLR.

The difference with encapsulation is overhead, I can choose and detect if I am validated either with Memoization or otherwise (caching).

It allows that portion of code to give it's own implementation if desired i.e. an IValidator which is a better encapsulation of multiple principles of OOP.

It also changes the state of a struct although I suppose you can already assign to this with structs in most cases and with classes through initialization and now that you mention static as well in the CLR due to state and guaranteed made about such which will NOT only be difficult to change now for everyone but can for that matter already be handled by the most determined either with a Host or Hijacking for better yet proper programming techniques which dont require us to do this in the first place.

Now for that matter I vote for this!

I'd in alot ways rather see this championed than default interface implementations...

Finally for that matter I would absokutely love to this feature on partial classes!

[yaakov-h]

[scratches head]

I don't get how any of that is relevant at all...

[munael]

Some restrictions that would allow some new constructs but might be easier to defend:

Example of allowed uses:

class Derived : Base {
    Derived(Foo foo) {
        // do bar and baz with foo
        base(bar, baz);
        //  blah
    }
}

1. Exactly one base constructor call in the Derived constructor call is allowed.
2. The base constructor call must have at least one argument (base(T)) (cannot defer a base() call).
3. The base call must be in the outermost scope of the Derived constructor body. So, you cannot put it in branches or loops.
   a. How about try blocks?
   b. if/switch statements with an exhaustiveness check (all branches call the base at least once)?
   1. This's basically asking for linear typing for the base constructor, which is implicitly passed along to other calls. So, for example, you satisfy the requirement for the exactly-one call by calling a different derived class constructor that satisfies it.
4. The base call is a statement, not an expression.

[KalleOlaviNiemitalo]

Inspired by dotnet/runtime#46489, it could be handy if a constructor could handle exceptions thrown by the base class constructor, a bit like a function-try-block in C++.

partial class VolumeStream : FileStream
{
    public VolumeStream(string path)
    {
        SafeFileHandle handle = null;
        try
        {
            handle = OpenVolume(path);
            int sectorSize = GetSectorSize(handle);
            base(handle, FileAccess.ReadWrite, sectorSize);
        }
        catch
        {
            handle?.Dispose();
            throw;
        }
    }
}

Sequence expressions (#377) do not support try statements and so would not be able to handle these exceptions.

I don't see any restriction against catching base constructor exceptions in ECMA-335. III.1.8.1.4 (Class and object initialization rules) even has a note that mentions this possibility.

After catching, the derived constructor would not be allowed to return; it would have to throw something or loop infinitely. A constructor of a value type could perhaps be allowed to assign to this and return, but that does not seem worth supporting because the ValueType() constructor is unlikely to throw. I don't think the derived constructor should be allowed to retry the base constructor after an exception, because the base constructor may assume that instance fields have default values, and the previous attempt may have modified them already.

The syntax could be distinguished from base(T) (#2910) by checking whether the closing parenthesis is followed by a dot or by a semicolon.

[KalleOlaviNiemitalo]

The example above has the problem that one would not know whether base() is implicitly called at the top of the constructor, without reading the rest of the constructor. It would be spooky action at a distance, like yield return in iterator methods. Perhaps it would be better to require something like : explicit base after the parameter list in the constructor declaration, to indicate that the default : base() does not apply and the body will explicitly call a constructor.

[KalleOlaviNiemitalo]

This would help in dotnet/runtime#38804.

[shadow-cs]

A little late to the party but I offer another workaround, similar to the out arguments but a little more readable (to me at least) is using a constructor overload with a tuple:

  public class Base
  {
    protected Base(int a, string b, Guid c) { }
  }

  public class Derived : Base
  {
    public Derived(SomeType t) : this(PreInitialize(t))
    {
    }

    private Derived((int a, string b, Guid c) p) : base(p.a, p.b, p.c)
    {
      // other init here
    }

    private static (int a, string b, Guid c) PreInitialize(SomeType t)
    {
      if (t == null) throw new ArgumentNullException(nameof(t));
      int a = CalculateA(t);
      if (a < 0) throw new InvalidOperationException();
      string b = CalculateB(t, a);
      Guid c = CalculateC(t, a, b);
      return (a, b, c);
    }
  }

I'm using the same sample as @HaloFour.

Also using this technique gives you more freedom on what you can pass and what to do with values in the tuple (the overloaded ctor can also use them and store them in a field if needed which isn't possible without using the overload).

[bernd5]

@shadow-cs nice workaround

AFAIK the tuple solution would just not work for by-ref parameters and ref-like types (e.g. Span) - but for by value calls it is nice.

[phizch]

Been a while, but.. The tuple could easily be replaced with a struct, or even a ref struct.
It does make it way more verbose though.

[ghost]

[FaustVX]

The age and name only exist before the base or this block.
So even base(age) and this(name) isn't possible.

[ghost]

I think if the block before the base or this does not free the stack, I should be able to use base(age) or this(name).

In fact, it is equivalent to this code.

public class A
{
    public A(int age)
    {
        ...
    }
}

public class B : A
{
    public B(string name)
    {
        // static only before the ‘base(age)’
        ...
        int age = 10;
        ...
        base(age); // end
    }
    {
        ...
    }

    public B()
    {
        // static only before the ‘this(name)’
        ...
        string name = "Test";
        ...
        this(name); // end
    }
    {
        ...
    }
}

[Rekkonnect]

Why would one go over this hustle and achieve the same thing that constructors inside the method body would enable?

[cyraid]

We all just talkin' in the wind again? Does talking here make a difference? How would one actually promote it into an idea the language heads could accept/reject?

[cyraid]

Yeah, I hear ya. This used to be an issue, but got locked and thrown into discussions: which is also fine, because then it can be hashed out. But like you said, it's the lack of direct communication that is apparent.

I think a nice voting system, even by number of thumbs (like other projects) so we know something would be considered, but hey. My two cents.

(Also seeing as it's been 4 years since the issue was created)

[CyrusNajmabadi]

Who needs to see it?

The language design team needs to see and approve it. We do continually watch, engage, and review everything here (I'm one of the design team members).

Where do we vote?

You can vote in the top post, leaving a thumbs up/down/etc.

Are there other cases where discussions got promoted to implementation?

Yes. Practically all language changes happen that way.

[CyrusNajmabadi]

This used to be an issue, but got locked and thrown into discussions:

"Issues" are where we work on approved features, and the design process and implementation tracking. Discussions are where design and free form thinking happens prior to being approved to be a future language feature.

But like you said, it's the lack of direct communication that is apparent.

You are getting direct communication. :-)

I think a nice voting system, even by number of thumbs (like other projects) so we know something would be considered,

We consider practically everything submitted to the repo (except things like spam/etc.). But, practically, we only will likely pick a small handful of items per release.

Also seeing as it's been 4 years since the issue was created)

Time has no bearing here. We do the work when we think it's the most suitable time. Sometimes that means 10 weeks later, sometimes 10 years :-)

[HaloFour]

This used to be an issue, but got locked and thrown into discussions.

Discussions are a relatively new feature to Github. Before they were added, all feature requests were created as Issues. But when Discussions became available it was decided that all requests would be moved to Discussions which have a threaded format, and Issues would br reserved to actual design and spec work for the language team.

[cyraid]

Thanks for the reply guys. Answered everything in one swoop, very clear answers too, I like it. I'm used to other projects where when thrown in discussions, it's like a graveyard. Nice to see the mold being broken, keep up the good work.

[ThaDaVos]

Bit late - but I think the general idea is to have to same functionality as Java/PHP has with their constructors - that you, the programmer, can decide when the base constructor is called:

PHP: https://www.php.net/manual/en/language.oop5.decon.php
Java: https://www.javatpoint.com/super-keyword

I also see some use to this - as it allows to transform an input argument for the constructor - or helps in clarity of the code even, as it's easier to read then some multilined base() because you have to include some huge argument based initializers for certain parameters (yes this can happen when you use external libraries and extend their class to add functionality and remove duplicate code)

The downside I see of the current workarounds (the out params and static function) - is that you it's freely to move around - so there's nothing preventing it from being moved anywhere except next to the constructor - by having the requested feature of being able to call base yourself inside the constructor - the code stays together and stays readable