Explicit non-nullable reference types

[forgotten-aquilon]

I feel like it should have proposed a long time ago, even with the same syntax, but I tried to search and found nothing.

Reasoning

Yes, you can enable warnings as errors, but it can still be overridden by suppression. But in this case it will be not just some kind of annotation, but treated as a separate type, which means it can be part of an API, so you are forced to handle it on your own.

Examples

public class A {}

A commonObject;
A! nonnullableObject;

commonObject = null; //Ok, even in non-nullable context
nonnullableObject = null; //Building error

public class C {}

public class D
{
    private C! _nonnullableField;
    D() {}
}
//Building error, because _nonnullableField is not initialized in a constructor.

public class E {}

public E SomeFunc() {...}

E obj = SomeFunc(); //Ok
E! obj2 = SomeFunc() //Building error, you should guarantee non-nullable initialization.

E! obj = SomeFunc() ?? new E(); //OK

var tempObj = SomeFunc();
E! obj3;

if (tempObj is not null)
{
    obj3 = tempObj; //Ok
}

public class F {}

public void AnotherFunc(F! obj) {...}
public F FFunc() {...}

F nullObj = null;

AnotherFunc(nullObj); //Bulding error

F notNullObj = FFunc();

if (notNullObj is null)
{
    notNullObj = new F(); 
}

AnotherFunc(notNullObj); //Ok

[HaloFour]

This was the original design for nullable reference types. The team decided against this approach because the expectation is the vast majority of the type the developer did not intend to accept null in the declaration and that it would not be a good design to require the developer to annotation 95% of their declarations. At that point it would just be noise.

[forgotten-aquilon]

Well, expected. Just want to share my experience when you work in a big company with multiple repositories and don't have an upper hand in theirs management, you are kinda forced to write a lot of boilerplate code with many null-checks just in case somebody will use your function and pass null (and it will happen 100%).