CS8618: Nullability of struct fields is not evaluated for implicit parameterless constructor nor in array creation (or at least when copying from an unintialized array)

[marchewek]

I've recently stumbled upon the following compiler behavior and I wonder if this was intentionally done this way (for whatever reason) or it's a bug (and in such case where to report it so that it won't be ping-ponged between repos):

struct S1
{
	public S1() { } // explicit parameterless ctor: CS8618
	public string Prop { get; }
}

struct S2
{
	public string Prop { get; } // no explicit parameterless ctor: no CS8618; expected: should be triggered
}
	
struct S3
{
	public S3(string x) => Prop = x;
	public string Prop { get; } // no explicit parameterless ctor: no CS8618; expected: should be triggered
}

class Test
{
	void CS8618DoesNotPropagate()
	{
		// no CS8618 below
		// expected: the access to default(S*)-initialized arrays should complain about not assigned notnull-marked Prop
		var hehe1 = (new S1[1])[0];
		var hehe2 = (new S2[1])[0];
		var hehe3 = (new S3[1])[0];
	}
}

[huoyaoyuan]

not assigned Prop, because the parameterless ctor (that should complain about it) is involved

This is incorrect. Parameterless constructor is not involved in array creation of C#.
For the following snippet:

Console.WriteLine((new S[1])[0].a);

struct S
{
    public int a;
    public S()
    {
        a = 1;
    }
}

prints 0.

I'm not recommending the usage of term "implicit parameterless ctor". It's actually the alias of default(T) which does nothing. In array creation, nothing is involved.

[marchewek]

Thanks for the non-defaultable struct link, it's good to see this in the pipeline.

Still, I'd argue that the nullable enabled context does not do its job in use cases involving structs. From the programmer perspective: I set up the nullable enabled context so that I can avoid null reference exceptions; yet there are situations that I will anyway encounter NREs.

If it's not possible to report that warning outside of a structure per particular struct based on its implementation, then I would expect the array creation and default(AnyStruct) to always report some compiler warning so that I am warned in compile time to ensure that I know what I am doing, instead of stumbling upon a NRE during the runtime. I know that for some structures this warning would be a false positive, but I consider this a better alternative to the current false negative. After all, I set up the nullable enable context for a reason - to be warned about potential NREs ahead of time.

[huoyaoyuan]

Still, I'd argue that the nullable enabled context does not do its job in use cases involving structs. From the programmer perspective: I set up the nullable enabled context so that I can avoid null reference exceptions

There are other cases like arrays. There's no language feature to require you to fully initialize an array, and the corresponding analysis can be very complex.

then I would expect the array creation and default(AnyStruct) to always report some compiler warning so that I am warned in compile time to ensure that I know what I am doing

It will be too noisy and unactionable. Moreover, there can be more cases it can't cover, including generic, reflection and interaction to incorrectly annotated components.

[marchewek]

I sometimes wonder - why bother introducing a feature (in this particular case "nullability checks to avoid NullReferenceException") if you can't (due to conflicting requirements) or don't want to (because it's too expensive)? Either do it, and do it well, or don't do it at all.

So bottom line is - nullability feature works for some cases while it doesn't for other and people are not bothered by that. If this trend continues, C# and its toolchain will see people switching over to more reliable alternatives.

[huoyaoyuan]

why bother introducing a feature

Because it's required to define an entire set of new rules, including annotations and emitted binaries around structs. The problem is simply unsolvable with scope of current rules.

nullability feature works for some cases while it doesn't for other and people are not bothered by that

Nullability does have hole as long as there's container types like arrays, and you can use them arbitrarily. Even languages with strict rules like Rust would need unsafe to make things efficient.

[marchewek]

Then there should be a very clear information on the documentation page that this feature is only partially implemented and is not planned to fully eliminate the NullReferenceException; the comment:

minimize the likelihood that your code causes the runtime to throw System.NullReferenceException

in my personal opinion is not explicit enough. The pitfall list should mentioned early in the documentation and there should be a bit more explanation why (and again mentioned that there is no plan to change it) so people are well informed ahead of filing a suggestion or a bug report.