Idea: Primary Unnamed Constructor Initializer for C#

[Mubarrat]

Hello, C# language enthusiasts,

I would like to share an idea for a new feature in the C# language: the Primary Unnamed Constructor Initializer. This feature aims to streamline object initialization by allowing methods or events to be set directly in the constructor initializer, providing a more concise and readable syntax. You can find the concept code and more details in my repository here: Primary Unnamed Constructor Initializer Concept.

Motivation:

The Primary Unnamed Constructor Initializer builds upon the existing primary constructor concept by enabling more flexible and expressive object initialization. This feature would improve code readability and maintainability, especially when dealing with complex initialization logic. This would be the successor of the Primary Constructor introduced in C# 12.

Idea:

The primary unnamed constructor initializer can be placed flexiblely. Here is an example to illustrate its usage:

// Concept class
public class Sample(bool startImmediately = false) : public() // "public()" here isn't necessary but it can be used to define constructor access. I think it should come first before any base class.
{
    // Unnamed Initializer. Can be used to execute flexiblely.
    OnStart += () => Logger.Log("Application Started");
	
    public event Action OnStart;
    public ILogger Logger { get; } = new Logger();

    // It will be executed after Logger property defined.
    if (startImmediately)
	Start();

    public void Start() => OnStart?.Invoke();
}

public interface ILogger
{
    void Log(string message);
}

public class Logger : ILogger
{
    public void Log(string message)
        => Console.WriteLine($"Log: {message}");
}

public class Program
{
    public static void Main()
    {
        var sample = new Sample();
        sample.Start();
    }
}

Explanation:

• The first independent statement executed first.
• Defined Logger property.
• Second Statements executed after property defined.
• The Start method invokes the OnStart event, demonstrating how the initializer sets up the necessary functionality.

Benefits:

• Enhanced Readability: By consolidating initialization logic into the constructor initializer, the code becomes more readable and easier to follow.
• Improved Maintainability: This approach reduces the likelihood of errors by ensuring that essential methods and events are set up at the beginning of the object's lifecycle.
• Concise Syntax: The primary unnamed constructor initializer allows for a more concise and expressive syntax, reducing boilerplate code.

Contribution:

I encourage the community to review the concept and provide feedback on its potential inclusion in the C# language. Let's discuss how this feature could enhance our coding experience and bring additional clarity to object initialization in C#.

Thank you for considering this idea.

[HaloFour]

How would public() work given that's where you'd already put a base(...) constructor call?

As for the initializer, I would rather that it appear in some kind of block and not simply as part of the class body as the latter could easily be ambiguous. This was a big point of contention with primary constructors as they were first discussed back in the C# 6.0 timeframe (unfortunately those conversations are buried in the CodePlex archive so it's not possible to easily link to them.)

[Mubarrat]

Sorry, I changed my mind. I want flexibility. See the other comment. Unnamed initializer now doesn't need to come first.

[Mubarrat]

The problem is how we can understand difference between field and variable. Since, initializers are flexible to class block, not in constructor block. So, there is no variable except in code blocks. Now what is the rule breaking changes?

[Mubarrat]

Now, the following concept example is:

// Concept class
public class Sample(bool startImmediately = false) : public()
{
    // Unnamed Initializer. Can be used to execute flexiblely.
    OnStart += () => Logger.Log("Application Started");
	
    public event Action OnStart;
    public ILogger Logger { get; } = new Logger();

    // It will be executed after Logger property defined.
    if (startImmediately)
	Start();

    public void Start() => OnStart?.Invoke();
}

Why using Start() is illegal. Start() is a void method? This would be illegal if we define it using return type Action field. You know that method can be defined anywhere in a class and can be called anywhere from same-class.

[HaloFour]

Initializers execute prior to the base constructor call, and as such they are forbidden from calling instance members. At most they can set instance fields, but they cannot call methods or property accessors. Given field initializers always execute prior to the base constructor call, in order to support lexical evaluation of "initializer" bodies intermingled with field initializers, they would have to execute at the same time. Thus, calling instance methods would be forbidden.

This restriction is because an arbitrary method may be able to invoke virtual members declared on the type, which could be overridden in a derived type, and if those overridden methods are called they could observe the state of the class prior to construction. This is why the runtime and language both forbid referencing instance members, aside from declared fields, in the constructor prior to the base constructor call.

[Mubarrat]

Sorry, I'm here not to change syntax. I wanted to create a new syntax which relays on existing syntax. I'll see replies tomorrow.

[FaustVX]

There is already a Final Initializer proposal #6591
I think it's better to have proper block of code rather than having code spread all over the class body.

[Mubarrat]

csharplang/proposals/final-initializers.md

Line 20 in 5055b97

As an example, consider a type which has properties for the year, month and the day. The month should be a value in the range 1-12 and the day checked against the `DateTime.DaysInMonth` method which uses the year and month. While this check can easily be done in a constructor, there is currently no way to do the check when object initializers are allowed. These checks could be done in the final initializer which would run after all constructors and initialization, including initialization done in code instantiating a member of the class.

According to your link reference, it says it'll execute after all constructors or initializers. But It would be ideal if it were executed before any property or field. Sometimes, we've to throw ArgumentNullException if the parameters are null. What do you do? Do you throw exceptions after defining a property or field, or before?

[Mubarrat]

Might be this:

// Concept class
public class Sample(bool startImmediately = false) : public()
{
    // Unnamed Initializer. Can be used to execute flexiblely.
    OnStart += () => Logger.Log("Application Started");
	
    public event Action OnStart;
    public ILogger Logger { get; } = new Logger();

    // It will be executed after Logger property defined.
    if (startImmediately)
	Start();

    public void Start() => OnStart?.Invoke();
}

public interface ILogger
{
    void Log(string message);
}

Translation Code:

// Concept class
public class Sample()
{
    public Sample(bool startImmediately = false)
    {
        OnStart += () => Logger.Log("Application Started");
        Logger = new Logger();
        if (startImmediately)
	    Start();
    }

    public event Action OnStart;
    public ILogger Logger { get; }

    public void Start() => OnStart?.Invoke();
}

public interface ILogger
{
    void Log(string message);
}

[FaustVX]

No, you'll change current behavior.
Current is, when you create an object :

1. field/Property initializer
2. base object creation (recursive)
3. constructor

So, if you move the step 1 inside the ctor, you'll introduce breaking changes

sharplab.io

That's why Final Initialzer come after the ctor

[Mubarrat]

Yes, then there will be no task in step 1.
This will become more flexible.
This initializer is part of the constructor, not like the final initializer or after the task of constructor.
The proposal final initializer is a different concept than I want to explain.
Didn't you understand my concept?
We normally do task in constructor if we don't use Field/Property initializer

[HaloFour]

See: #1026