Why does not compiler compliain about non-initialized reference type members declared in structs?

[voroninp]

struct Foo
{
	public byte[] Bar {get;set;}
}

Not complaining.

class Foo
{
	public byte[] Bar {get;set;}
}

Emits CS8618 warning.

Yes, I understand, that record can be created without init logic of constructor being called, but that means the default value is semantically invalid. I've declared Bat as byte[], not as byte[]?, and I expect it to be not null.

Isn't it more correct to require all ref types in structs be nullable?

[CyrusNajmabadi]

NRT balances usefulness with accuracy. We deemed it too obnoxious to have to always nah Mark this as nullable and then have to deal with that at use sites. As most code doesn't run into default structures it was just onerous and massively increased the noise versus the signal.

You can of course create an analyzer here trivially that would require you to make these all nullable and then have to deal with all the fallout.

[RikkiGibson]

One behavior people might find useful out of such an analyzer would be to tell you to make any such properties required, perhaps only if the type does not declare any constructors.

[TahirAhmadov]

Was it considered to track the state of struct as being default or not? Maybe, an attribute on method parameters and such:

struct Struct { public Struct() { this.Str = "abc"; } public string Str; }
void Foo(Struct s)
{
  int l = s.Str.Length; // NRT warning
}
void Bar([NotDefault] Struct s)
{
  int l = s.Str.Length; // no NRT warning
}

Struct s = default;
int l = s.Str.Length; // NRT warning
Foo(s); // no NRT warning
Bar(s); // NRT warning
s = new Struct();
int l2 = s.Str.Length; // no NRT warning
Foo(s); // no NRT warning
Bar(s); // no NRT warning
// etc.

[RikkiGibson]

I don't think == is automatically defined on structs. It only exists if the user declares it (or if it is a special type).

[voroninp]

@HaloFour Also validity is a contextual thing, so if we treat constructor as a function which maps input values to struct, then the very fact that constructor was not explicitly called could mean a logical error, despite default value belonging to function domain.

[HaloFour]

@voroninp

Also validity is a contextual thing, so if we treat constructor as a function which maps input values to struct, then the very fact that constructor was not explicitly called could mean a logical error, despite default value belonging to function domain.

This is something that someone needs to keep in mind when they try to define such a type. All structs have a default zeroed-out value, that is their nature, and you need to define such types to account for this. Either<TLeft, TRIght> as a struct would have to account for default just like it would have to account for null if it were a class instead.

[theunrepentantgeek]

I don't think == is automatically defined on structs

I stand corrected. You're right.

[voroninp]

@HaloFour , yep, I used private boolean field for that, but defaultness is why I tend to avoid records with behavior.
And that's why I have strict rule for enums: default value should never be a valid domain value.