Late initialization for properties and fields when null reference type is enabled

[idlist]

Related: #2452, #7081 (and maybe #3963)

Late initialization is an unavoidable topic especially when C# is used as a script language of some framework and engine, where some initial values cannot be set until some lifecycle (Setup(), Ready() or whatsoever), or those values are set by external sources. The issue is that current NRT checking cannot recognize those patterns, and would give annoying warnings about them.

newing an empty one as a placeholder isn't always ideal in these cases, as the properties or fields requiring late initialization may involve heavy computation.

Currently, for properties I can, verbosely, have (T : class)

private T? _value;

public T Value {
  get {
    if (_value is null) throw new InvalidOperationException();
    return _value;
  }
  set => value;
}

But for fields, this isn't the case. The only thing I can do is

private T _value = null!

to make the NRT checking happy.

Also, in the specific framework I use (Godot), it use an attribute [Export] (and related source generation underlying it) to expose a value to the editor, which means that having a wrapper (like LateInit<T>) for that would break the source generation and thus is not a solution. On the other hand, having each property requiring late initialization written as above would be tedious and, in my opinion, is no better than null! compared to the verbosity it brings.

Kotlin has lateinit which has better semantic meaning than null!. I wonder if C# could have something similar.

[En3Tho]

I don't really see how lateinit has better semantics than a null! . Am I missing somrthing? Name is obviously more indicative of an intent but I wouldn't call it "semantics".

If you simply want something similar name-wise you can introduce a helper along the lines of

public static T LateInit<T>(string hint) => default(T);

class Foo() : ScriptObject
{
    string bar = LateInit(nameof(this.Setup));
}

Or something like that to give you a small hint where the thing is actually initialized.

[idlist]

I would agree that whether lateinit is necessary or not would be vary from people to people. The issue and discussions I mentioned are raised by those who think it's better to have, while I consent that others may accept null! as a final solution, I'm on the side of "having one is better", so I would not debate on the point.

I can't see how the helper is helpful, though. An example about lifecycle is:

public partial class MyNode : Node {
  private InvertedController _controller = null!

  // The "Ready" lifecycle, until when some methods on "this" is usable without causing errors in the engine,
  // and the "InvertedController" would use those methods.
  public override void Ready() {
    _controller = new InvertedController(this);
  }
}

Another situation about engine-set values is:

public partial class MyNode : Node {
  // A complex node having a string property "Message".
  // The value (or to say, the reference) of the node is set by the engine via some GUI or other configuration file.
  [Export] private MyOtherNode _otherNode = null!;
  
  public override void Ready() {
    // "_otherNode" should never be `null`, or the program should be blown up if "_otherNode" is null.
    Engine.Console.WriteLine(_otherNode.Message)
  }
}

Neither of the situation would benefit from your snippet, which... simply gets the name (in string) of the lifecycle.

[NN---]

lateinit has also a better error message when used incorrectly.
Not just a random NullReferenceException without any additional data.

[En3Tho]

Well the idea of a snippet was to introduce a way to have a clear indication of lateinit and a small hint to yourself as a bonus. It is obviously not a language feature that tracks the initialization lifetime. So using these examples of yours:

public partial class MyNode : Node {
  private InvertedController _controller = LateInit<InvertedController>(nameof(Ready));
  private InvertedController _controller2 = LateInit<InvertedController>(nameof(Setup));
  
  public override void Setup() {
    _controller2 = new InvertedController(this);
  }

  public override void Ready() {
    _controller = new InvertedController(this);
  }
}

By using this helper you can from a glance see where fields are initialized. There is nothing guarding you from not initializing anything but just a small hint to make things explicit. It is verbose compared to null! though.

[idlist]

This reminds me of having Noop() {} (with some ignore pragma) to confront some linter rules about not allowing empty blocks, etc. I would like to say it would be a good compromise if T in LateInit<T> could be inferred so the calling becomes LateInit(), though it seems like it is still a step away. For example, TypeScript, though being a different language, could do the infer:

const lateInit = <T,>() : T => null!;

class SomeClass {
    constructor(public x: number) {};
}

let aClass : SomeClass = lateInit();

For now I'm sticking to using null! until better alternatives appear.

[NN---]

In Kotlin you don’t have fields. What you see is actually a property.
So the better way to look at it is Kotlin’s lateinit could be C# attribute with a source generator.

I am not familiar with this library, why doesn’t source generator work here?

[NN---]

Point 2 is already mentioned with syntax "null!".
It might not be as nice as lateinit but it is a well known common pattern for late initialization.

[idlist]

Yup, I'm raising this discussion because I still want a nicer null! (though it has been raised and declined for several times). I know it is a personal bias, but null! itself doesn't look right to me, especially when I'm repeating it for hundreds of times where I do not have other better options.

[NN---]

You can also use default! if this looks nicer to you.

[idlist]

The point is that I feel like I should not give the late initialized properties or fields any initial value at the time of constructing - they're definitely initialized later, but not now. Giving them value (which is forced by NRT) looks really weird to me. Again I would stress that this is more of personal bias, but I'm not satisfied with existing solutions (and I'm not the only one), and I'd like to add my little bit effort to hopefully push the thing slightly forward (or...not, sadly).

[NN---]

I understand your point.
Probably, given that null! already solves this, making a new keyword just for that is not enough for changing the language.

[idlist]

After some more investigation I feel like I would try to have a custom DiagnoticsSuppressor with attributes like [LateInit] to suppress CS8618 in my spare time. Meanwhile I'll continue leaving the discussion open to stress my original thoughts.

[bernd5]

Why you don't use Lazy?

[idlist]

Lazy<T> is distinct from lateinit with different purpose:

• Lazy<T> means it is not necessarily to be initialized and is to be initialized when it's to be used. It is more for optimization;
• lateinit means it is definitely to be initialized and is meant only to be used after the initialization, but for some reason described above, it cannot be initialized in the constructor and thus NRT complains about it.