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, updated the post; is it better now?

[huoyaoyuan]

It's not about the wording in the example, but the expectation for these cases.

First, at the view at caller site, it doesn't know about the internal implementation of the struct. CS8618 can only be reported inside the definition of a struct. new S1() won't provide any warning because it doesn't know what's happening inside it. For new S2 and new S3, the call also can't know S2 and S3 has field of reference type.

No matter how you define a struct, default(S) will always be available and left fields with null. The non-defaultable struct mechanism is necessary to solve this.

[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.