Proposal: Final Initializers

[KathleenDollard]

Let's talk about final initializers.

The Final Initializers proposal

Consider a constructor that expects a value in a range, such as 1-12 for months. Currently, if you switch to initializers you cannot do this validation. Also, multiple constructors must explicitly do this validation, or call constructors that do.

The proposed final initializer would run after all construction steps and be a logical home for this type of validation.

[ardalis]

If this can ensure that instances of a type are always in a valid state, it would be a great addition for record types, which currently allow bypassing of constructor validation checks through the use of the with keyword. A good summary of the problem this can create is in this article: https://enterprisecraftsmanship.com/posts/csharp-records-value-objects/

[Joe4evr]

As long as you can disregard construction by reflection or other type-hackery, yes.

[TahirAhmadov]

Great! A few questions:

• Isn't sprinkling the initializer to all types a performance hit? I read further through the draft and it mentions the possibility of doing "discovery" - I think that's preferable. Specifically, it should be compilation-based discovery (at least, for 99% of the times).
• Regarding calling the base - I'm conflicted on this, on the one hand, it sounds too restrictive to mandate that base is always called, because there may be an edge case where it's undesirable. On the other, 99% of the time, base should be called. Maybe it should be an "opt-out" syntax? Perhaps, something like new init { ... }.
• I supposed this would be supported on structs as well, right?
• Reflection - I imagine this "validator" can be called using Invoke? This may be needed in a few scenarios.
• Reflection 2 - what about when an instance is constructed using reflection? We don't plan to call these validators from Activator.CreateInstance, etc., right?

[Joe4evr]

I had thought about such a shape before, but concluded that it makes it harder for callers to cache the MethodInfo for cases they expect to call it on many instances quickly. On the other hand, if the API caches the method by default, it may keep the MethodInfo alive for longer than desired when the caller doesn't expect to reuse it quickly.

So making it the caller's responsibility to decide how to use the MethodInfo object is the simplest solution and makes it more consistent with other APIs on Type as well.

[jnm2]

You may be working with expression trees or IL emit and then you need a MethodInfo also.

[TahirAhmadov]

@Joe4evr @jnm2 good points, I agree that we need the GetFinalInitializerMethod method, but I think the simple InvokeFinalInitializer should also be there. And regarding caching the MethodInfo instance, why not do a lazy field cache behind the scenes? Shouldn't that be sufficient usually?

[Joe4evr]

That's what I meant with

if the API caches the method by default

[TahirAhmadov]

@Joe4evr so your concern is that if the initializer is called for a type once, but then not used for a while, that instance of MethodInfo sticks around and takes up memory? Are those instances heavy memory-wise? Is it a significant problem to be worried about?

[FaustVX]

I really like that idea.
But I would prefer init() {} with (), similar to static ClassName() {}.
Also, I prefer having to explicitly call the base() anywhere in the method body.

[TahirAhmadov]

What if base class has a method named init? It's legal today.
Also, if anything, these initializers/validators are more akin to constructors, and those use the : base() syntax - albeit, it's different in that it's not in the body.

[FaustVX]

You're not wrong 😄

[DougLeonard]

What if base class has a method named init? It's legal today.

I think the point here is what if there's already a conflicting named-method. Of course that's a concern in an existing concrete class too (so either I'm missing the point or it's an issue for both).

If I'm not missing the point one solution, as I posted below is to use:

private init() {  // note lack of  return type
  ...
}

I believe nothing is allowed to have that syntax at present. It's not ideal. Would it be allowed to be public? If so it then there is still a conflict of how to call it if both exist, but existing code would not have a conflict, so that could be handled by compiler error still.

[spydacarnage]

Apart from a class named init, because while that is frowned upon, it is not currently illegal.

public class init()
{
    private init() { }
}

is currently valid syntax.

[DougLeonard]

Fair enough. Although it is solved by a simple exception that a class named init will interpret private init() {} as a ctor, and that it simply cannot have a final initializer. Existing classes continue to work and the future restriction is not so intrusive.

Another option, though, maybe a little ugly, is __post_init(). The biggest thing against it may be that it's very difficult to type in markdown editors like this one :). As far as I can tell double underscore is reserved.

[GitClickOk]

I suggested it in another thread and I'm posting it here. Maybe it can be easier/more straightforward to use IAsyncLifetime as a first citizen interface like IEnumerable.

[NN---]

For my understanding the init block is called after properties init.
The name should reflect this.
Calling it init makes it unclear.

[tuscen]

Is there any movement on this proposal? I really like required properties, but I'd also like to have an ability to validate them without explicitly writing setters for each required property and also to compute other non-settable properties using values from the required ones.

[CyrusNajmabadi]

@tuscen No. The proposal lacks a champion. If we do anything here, we will update the issue automatically. Thanks.

[TonyValenti]

I would love this as well.

[gfraiteur]

We (Metalama / PostSharp) support this proposal.

Use cases

Final initializers are an important feature in implementing the following patterns:

• ChangeTracking / IsDirty -- changes done before the final initializers don't need to be tracked
• INotifyPropertyChanged -- changes done before the final initializers don't need to be notified
• Locking -- changes done before the final initializers don't require synchronizations
• Immutable / Freezable -- changes are allowed before the final initializers, forbidden after
• Software Transactional Memory -- changes done before the final initializers belong to the same transaction as the construction itself

Analogies

This feature shares similarities with the OnDeserialized method of various serializers.

It would be useful for the final initializer to be exposed as an interface method so that deserializers could use this method instead of a custom one.

An InitializationReason parameter could be added to the final initializer method, with the following possible values:

public enum InitializationReason
{
  // Explicit use of the constructor with or without field/property initialization clauses. 
  // This value is typically used by the compiler.
  Construction,

  // The object was deserialized. Typically used by the deserialization library. 
  // Typically a post-deserialization callback should be allowed to have access to `init`-only fields
  Deserialization,

 // The object was cloned. (To be considered)
 Clone

}

Difficulties

A difficulty in classes that are part of class libraries is that they may be used by a compiler or library that does not understand the new specification. However, for some use cases, it is crucial that the constructor knows that the final initializer will be invoked.

For instance, when implementing change tracking, I might want to enable change tracking immediately before the constructor exits, instead of in the final initializer, if I know the final initializer won't be called.

A possible solution is to add another element to the specification: an optional constructor parameter of type ConstructorContract:

public struct record ConstructorContract( bool ShallInvokeFinalInitializer );

If a compiler or a library implements the specification, it must support both elements:

1. Set the optional parameter ConstructorContract.
2. Invoke the final initializer

Final initializers are very useful in implementing several patterns, and we're looking forward to this feature.

[DougLeonard]

I really want to voice support an justification for this proposal. Having properties that we can't validate or post-process as a collection, not just indivdually, seems to go against encapsulation principles. I don't agree that fixing that represents a complication to the language. Maybe init properties should have come before the constructor, but they didn't, and that's where we are.

An example in real code:

This is a real piece of draft code I wrote as a workaround:

public class Isotope {
    //init parameters
    public required string IsoName { get; init; }
    public required string Element { get; init; }

    //init parameters with dependencies
    public required int N { get; init { field = value; UpdateDerived(); } } 
    public required int Z { get; init { field = value; UpdateDerived(); } }
    public double HalfLifeSeconds { get; init { field = value; UpdateDerived(); } } = 0;

    //derived properties, 
    public int A { get; private set; } 
    public double TauSeconds { get; private set; }
    public double LambdaSeconds { get; private set; } // Decay constant (λ) in 1/s

    //Update Derived Properties
    private void UpdateDerived() {
        A = Z + N;
        TauSeconds = HalfLifeSeconds / Math.Log(2);
        LambdaSeconds = Math.Log(2) / HalfLifeSeconds;
    }
...
}

Clearly this is verbose, I am forced to call code at least twice that only needs to run once, and those private set specifiers are not ideal. They don't promise immutibility. I could solve that with backing fields at the cost of even more verbosity.

But obviously this would both look better and function better:

public class Isotope {
    //init parameters
    public required string IsoName { get; init; }
    public required string Element { get; init; }

    //init parameters with dependencies
    public required int N { get; init;} 
    public required int Z { get; init;}
    public double HalfLifeSeconds { get; init;} = 0;

    //derived properties, 
    public int A { get; }
    public double TauSeconds { get; }
    public double LambdaSeconds { get; } // Decay constant (λ) in 1/s

    //Update Derived Properties
    init() {
        A = Z + N;
        TauSeconds = HalfLifeSeconds / Math.Log(2);
        LambdaSeconds = Math.Log(2) / HalfLifeSeconds;
    }
}

Much cleaner, much less duplication, no more private set.

This particular example could be handed with expression-bodied members, but using

public double TauSeconds => HalfLifeSeconds/ Mat.Log(2);

Adds a computation on every get, and I will likely be using this in an fast loop.

Feasibility and implementation

This meeting note Indicated that it's very complicated. And it may be. I'm no compiler programmer.

But I notice that aside from maybe fixing the private set problem, I could in principle do it right now using a pre-processor or manually:

1. generate a dummy init-only auto-property. public int _post_init__ {get; init => {init();}}
2. Reject any manual use of the init property initializer.
3. Inject a useage of the initializer as the last initializer into all ctor calls.
4. To be picky, at the moment, init() needs standard keywords added back.

Maybe there are better or more desirable implementations, but it can't be too evil or full of gotchas because this way already seems pretty good, and is already supported, useable mechanics now. We just don't have syntax enforcement for 2 and 3 in particular, which are important but are just enforcement, not new mechanics. Basically a linter could do that.

Existing Alternatives

In this case, I could just use traditional ctor parameters and readonly ({get;}) properties and probably should. But if you start with init parameters then you're stuck if you need to add on derived values later. Also init paramers seem to me to have advantages for setting default values with less verbosity, maybe especially with inheritance. At present though, init properties seem like a feature that isn't quite there, maybe should even be avoided.

(Edited for code highlighting)

[DougLeonard]

I rethought this post (this one, not above) a little, but anyway did have a point that survived, and then found it matched with the meeting from 5 years ago, linked indirectly through the top post:

https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-04-27.md#primary-constructor-bodies-and-validators

ie that an init() (or maybe post_init()?) declared without a return type would avoid breaking existing code. Five years later, I think that's still true.

The thing I rethought was a misplaced frustration that the problems here apply even to {get; set;}, but then that's probably not really a valid concern in that case.

Edit: As spidacanage pointed out above, classes named init (or post_init or whatever) would have collisions, but they can just be banned from having a final initializer. Also duplicating from there, double underscore seems to be reserved (so would seem could be used).