Add an attribute to indicate a property won't return null even if it isn't set after initialization.

[JustNrik]

Sometimes we want to expose a class that we know they have properties that won't return null, but these properties aren't set during initialization but later, but guaranteed to be set before exposed to the user.

Example:

Currently:

public class Foo
{
    public string Bar { get; internal set; }
}

var foo = new Foo(); // private/internal construction
// some more private/internal stuff that will eventually set foo.Bar to an actual value
string bar = foo.Bar; // but there's warning on user code when it will never actually be null

Suggestion: Add an attribute for this case, something like LateInitialized? or WillNotBeNull or Idk I really haven't come up with a good naming.

Current work arounds

1. Add [AllowNull] to the property: It works, but it doesn't show the intentions clear. I wish there was an attribute specifically for this use case rather than an unclear work-around.
2. Use ! when you initialize it then set it later: It works, but I don't want to shup the compiler just because why not, I want an attribute that shows my intentions clear.

Also, can anyone come up with a better name for this attribute?

[jnm2]

1. Add [AllowNull] to the property

It would be [NotNull] rather than [AllowNull], wouldn't it?

[JustNrik]

I haven't tried it but I think it wouldn't work because the compiler would complain about it not being initialized yet, while AllowNull allows it to stay initialized at null while it still returns non-null, which is what I want but AllowNull doesn't show the intentions clear, which is why I want a new attribute for this use case.

This is mostly for clarity since this is already possible with AllowNull or Null-forgiving operator, just not in a way that I can see and say "I intentionally wanted this to behave in this way" but rather "This looks awkard and doesn't look like what I want but it works as I expect it"

[jnm2]

Oh thanks, I see. = null! or = default! is usually what is recommended then. See for example https://docs.microsoft.com/en-us/ef/core/miscellaneous/nullable-reference-types#non-nullable-properties-and-initialization.

[JustNrik]

I'm aware that I can use !, but that doesn't show the intentions clear, that's just a "shut up compiler, I know what I'm doing" rather than "Don't worry, I will set this later before anyone calls the getter".

[jnm2]

Can you help me understand the cash value of the difference between those two things?

[huoyaoyuan]

Such code is quite anti-pattern for nullable initialization.
A more reasonable action is to mark the initialization of the property in certain known-to-be-initialization syntax. It can be construction, object initialization block (with required property).

[JustNrik]

I don't think it's an anti-pattern, this is closer to a sort of Lazy, except that it isn't lazy exactly, just initialized at a later point out of the initialization context but before it's exposed to the user. Again, [AllowNull] already works, is it an anti pattern? It isn't, but it doesn't show the intentions clearly since I don't want to allow null values on the setter, I only want the setter to be initialized later before the getter is ever called. Another way would be a nullable property with getter's return's having NotNull attribute, but that currently doesn't work since the property is still nullable and will be treated as such.

[huoyaoyuan]

but before it's exposed to the user

The term user is very unclear.

just initialized at a later point out of the initialization context

I know there are situations like EF that properties are initialized after constructor. But it uses reflection and cannot benefit from annotations.

The question is: why you need to actually construct the object before initializing it's property?

[JustNrik]

Socket entities, something similar to EF but without reflection. Basically when you wrap an API, sometimes you can't fully construct the object in a single request, you have to do it throught two or more. In those cases, the final object won't have null properties, which is what is exposed to the user, but there's no way to show this intention clearly in the code. [AllowNull] allows this but it basically says "you can set this prop to null" when that's not the intention, the intention is that it won't be ever set to null, but just initialized at a later point before the getter ever gets called. default! / null! also don't show the intention clearly, they are just to supress the warning, it gives the same vibes of #nullable disable which defeats the purpose of this feature. I know the analyzers aren't perfect, but this kind of suggestions is to improve them and handle more cases without needing work-arounds.

[DaZombieKiller]

I've experienced a similar situation in the Unity game engine, as you cannot (safely) use a constructor to initialize things due to restrictions on what threads can access the API. You must instead rely on a method (void Awake()) called by the engine upon creation of the object to initialize things.

As a temporary workaround, I add a using to the top of the file:
using LateInitializedAttribute = System.Diagnostics.CodeAnalysis.AllowNullAttribute;
Which allows me to write [LateInitialized]. I'm still technically using [AllowNull], but the code's intent is clearer.

[JustNrik]

I guess this is the closest we can get until an actual attribute is added