Indicate that a non-nullable Field must be initialized where the type is constructed

[YairHalberstadt]

Problem

Consider the following three outstanding issues with NRTs

1. Object Initializers

Object initializers are greatly loved by many C# programmers. However they don't interact very well with NRTs.

Consider this for example:

public class C
{
    public string Str {get; set;}
}
...
var c = new C { Str = "Hello World" };

If Str is to be non-nullable, then when enabling nullability we are forced to completely change all this code:

public class C
{
    public C(string str) => Str = str;
    public string Str {get;}
}
...
var c = new C("Hello World");

Making object initializers usable only be nullable properties and fields.

2. DTOs

Many DTOs are initialized by ORM/Serialization frameworks. As a result they often contain only property getters and setters, without any constructors.

This of course causes warnings when NRTs are enabled, as it doesn't know the properties are always initialized by the ORM/Serialization framework.

3. Structs

Structs always have a default constructor, which cannot be overridden.

As a result whenever a struct containing a field of a non-nullable reference type is constructed using the default constructor, the field will initially be null. This leaves a big hole in the nullable-type-system:

public struct S
{
    public string Str { get; set; } //no warning
}
...
var s = new S(); //no warning
var l = s.Str.Length; // kabam! NullReferenceException! - but no warning

Solution

Based on a suggestion by @Joe4evr #36 (comment)

The real issue here is that present mechanisms only allow us to guarantee a field is initialized inside the constructor, but currently many types rely on their invariants being upheld by whoever constructs the type.

It should be possible to mark that a field/auto-property must be initialized at the point it is constructed, before it is used. This could be done via an attribute for example:

public class C
{
    [MustInitialise]
    public string Str {get; set;}
}
...
public struct S
{
    [MustInitialise]
    public string Str { get; set; }
}

Then when an instance of the type is constructed, it should be a warning to use the type before all such fields are initialised:

public class C
{
    [MustInitialise]
    public string Str {get; set;}
}

...

var c = new C { Str = "Hello World" };
var l = c.Str.Length; //no warning
c = new C();
var x = c.Str; //warning
c.Str = "Hello"
var l = c.Str.Length;  //no warning

...

public struct S
{
    [MustInitialise]
    public string Str { get; set; }
}

...

var s = new S { Str = "Hello World" };
var l = s.Str.Length; //no warning
s = new S();
var x = s.Str; //warning
s.Str = "Hello"
var l = s.Str.Length;  //no warning

All structs should have this attribute on all their fields implicitly.

Further issues

Consider this struct:

public struct S
{
    public S(string str) => Str =str;

    public string Str { get; set; }
}

Then it would be a warning not to initialize S.Str when the the new S(string) constructor was called, even though S.Str was initialized by the constructor!

I think the solution to this would be for the compiler to detect which constructors initialize a field, and implicitly add parameters to the MustInitialize attribute which indicate which constructors did not initialize the struct.

ie. the compiler should generate code equivalent to the following:

public struct S
{
    public S(string str) => Str =str;
    
    [MustInitialize("DefaultConstructor")]
    public string Str { get; set; }
}

then, when the default constructor is called, the compiler knows it must make sure S.Str is initialized.

[Kukkimonsuta]

This seem to be already the case for structs, however follwing is an issue right now:

static void Foo(S s)
{
    var l = s.Str.Length; // kabam! NullReferenceException! - but no warning
}

static void Main(string[] args)
{
    var s = new S();
    Foo(s);
}

[GeirGrusom]

In Kotlin this feature is called lateinit and is a modifier applied to properties.

class C {
  lateinit val str : String;
}

Basically it says that the property is not properly assigned by the constructor but will be assigned at a later point.

[DarthVella]

Great idea, but there's some discussion points that should be addressed quickly.

What of internal initialization methods?

class C
{
    [MustInitialize("DefaultConstructor")]
    public string Str { get; private set; }

    public C() { }

    [Initializes("Str")]
    public void Init(CHelper helper)
    {
        Str = helper.GetHello();
    }
}

Similarly, what of external methods that might allow or disallow uninitialized values?

class C
{
    [MustInitialize("DefaultConstructor")]
    public string Str { get; set; }
}

static void Main()
{
    C c = new C();
    
    UseString(c); //warning?
    SetString(c); //should not be a warning?
    UseString(c); //no warning?
}

[Initializes("c.Str")]
static void SetString(C c)
{
    c.Str = "Hello!";
}

[MustBeInitialized("c.Str")]
static void UseString(C c)
{
    Console.WriteLine("String length is: " + C.Str.Length);
}

For the record, I would assume that this proposal strictly deals with immediate initialization by the caller, and that these considerations are not within the intended scope.

[YairHalberstadt]

@DarthVella
In the long term some sort of attribute language might be necessary, but in the short term I believe this proposal represents a minimum viable product.

[DarthVella]

I should have mentioned that the attributes were only to show the intent, not to suggest that that level of user input was necessary.

[Joe4evr]

I'm generally supportive of the case to have finer granularity over what fields should get initialized by the caller, but I think there's a lot to be said to also have an attribute that can simply cover the whole type in one go. It could be the same, if an appropriate name is available, but my point is that code looks tidier with less attributes all over the place.

EDIT: I just realized there's one more caveat that would need to be filled for that to work smoothly: Externally generated values. A typical EF entity would have the ID generated when added to the database, and it'd be quite annoying to see warnings for those. 🤔

[Joe4evr]

Brainstorming another potential name for this attribute: CallerInitialize?

[ZeroUltimax]

All examples so far were shown using a String field, but I'm certain this could very well apply to value types as well. It seems to me that, since value types have an automatic default constructor, this would ensure proper initialization of nested members.

Ex.:

public struct S
{
    public string A {get; set;}
}

public class C
{
    [MustInitialise]
    public S Data {get; set;}
    
    [MustInitialise]
    public int MoreData {get; set;}
}

Does this seem like a proper usage? It seems to fit in with the spirit of annotating what must be initialized by the caller.

[YairHalberstadt]

@ZeroUltimax
Related: #146

[ZeroUltimax]

#146 is about the usage of default() for all instances of the structure. Here, I'm suggesting that in some cases, you might want to enforce initialization a member, which happens to be a value type.
For example, int MoreData could be an application specific code that shouldn't be left to default. In that case, #146 doesn't apply.

[YairHalberstadt]

@ZeroUltimax
I understand. I was just linking another issue which involved treating the default state of a struct as null.

[alexk8]

I think I'm going to close my #2411 (as a duplicate).
Therefore I'm copying here the general idea from there:
[MustInitialize] would be quite messy (used everywhere), this behaviour should be default by design IMHO. My suggestion:

class A{
  public string str; //do not warn "not initialized"
}

void Main(){
  A a1 = new A(); //do warn: "str is not initialized"
  A a2 = new A{str="str"}; //ok
}

that becomes a bit tricky with constructors, I suggest this

class A{
  public string str1;
  public string str2;
  public A(){  
    this.str1="123";
  } //warn: "str2 is also must be initialized"
}

Just a suggestion