Should non-nullable types allow temporary assignment of possible null value?

[SoftCircuits]

I'm trying to convert code to use Nullable. But I'm finding a lot of examples where there is no change a non-nullable character could ever be assigned null, but the compiler isn't smart enough to recognize that fact so I have to unnecessarily rewrite my code, in some cases such that it becomes less efficient and/or less readable.

For example, shouldn't the compiler be smart enough to recognize that the variable s in the code below always gets initialized?

string s;

s = MayReturnNull();
bool isEof = (s == null);
if (s == null)
    s = string.Empty;

How about something like the following. Why should method A have to verify array is not null if it can never be null?

void A()
{
    int[] array;
    FillArray(ref array);
    for (int i = 0; i < array.Length; i++)
        // Access array[i];
}

void FillArray(ref int[] array)
{
    int n = ??? ;
    if (array == null || array.Length != n)
        array = new int[n];
    // Populate array
}

Finally, here's one I've seen elsewhere. I get a warning here even though s2 always gets initialized.

class C
{
    string s1;
    string s2;

    public C()
    {
        s1 = string.Empty;
        Init();
    }

    void Init()
    {
        s2 = string.Empty;
    }
}

[HaloFour]

Shouldn't the compiler be smart enough to recognize that the variable s in the code below always gets initialized?

It is, which is why it will not warn if you try to consume s after this block of code.

However, the assignment of a nullable value to the non-nullable variable is enough to cause the warning. If you don't want that assignment to warn you can declare s as nullable or you can use the ! operator.

[SoftCircuits]

I'm saying shouldn't the compiler be smart enough to recognize that, while s could temporarily be assigned a null value, the block of code correct ensures it is initialized, and therefore doesn't warrant that warning. The point of this entire exercise is to guard against null references, which my code accomplishes. So a warning is not needed.

If I declare s as nullable, now I get warnings if I pass it to other methods--that is completely unnecessary here as the variable will not be passed as null.

I'll probably end up using the ! operator here, but would prefer something the compiler can verify.

[HaloFour]

If you declare a variable as non-nullable then it will warn on assignment. That is by design.

The compiler also tracks the nullability of the variable through the flow of the method and will generally know when the variable is definitely assigned a non-null value. It will not warn if you then pass that variable to a method that wants a non-nullable value:

string? s = MayReturnNull();
if (s == null) {
    s = string.Empty;
}
MustNotAcceptNull(s); // will not warn here

The other option is to use the null-forgiving operator, !, to tell the compiler that you know better:

string s = MayReturnNull()!; // will not warn here
if (s == null) {
    s = string.Empty;
}
MustNotAcceptNull(s); // will also not warn here

[SoftCircuits]

I understand it's by design. But I don't agree that whatever is by design is necessarily the best way. Again, the whole point of this is to guard against a null reference. How could my example ever cause a null reference? That's what I'm questioning.

I will likely use the null-forgiving operator because I do know better. But would prefer if the compiler was smart enough to verify I'm right.

[333fred]

The warning you are getting there is CS8600, which is one of what we call non-safety nullable warnings. They cannot cause direct null reference exceptions, true, but you are taking a location annotationed to be non-null and putting null into it, which merits a warning. However, we anticipated that some people would find it annoying, and made sure that this warning, 8600, was the same everywhere. You can disable CS8600 in your project file with NoWarn and you'll get the behavior you want.

The null suppression operator is not a good workaround here. It will tell the compiler "No, really, this value is non null", and that affects flow analysis.

[RikkiGibson]

Finally, here's one I've seen elsewhere. I get a warning here even though s2 always gets initialized.

class C
{
    string s1;
    string s2;

    public C()
    {
        s1 = string.Empty;
        Init();
    }

    void Init()
    {
        s2 = string.Empty;
    }
}

See dotnet/roslyn#32358