Nullability of generic type at runtime (.NET 7.0)

How can I determine at runtime whether a generic parameter is nullable or not? I was hoping that the NullabilityInfoContext class would solve the problem, but that doesn't work either.

Is there a solution for this?

using System.Reflection;
namespace ConsoleApp;

public class Item<T>
{
    public required T Value { get; init; }

    public bool IsNullable()
    {
        var nullabilityInfoContext = new NullabilityInfoContext();
        var propertyInfo = this.GetType().GetProperty(nameof(Value));
        var nullabilityInfo = nullabilityInfoContext.Create(propertyInfo);
        return nullabilityInfo.ReadState == NullabilityState.Nullable;
    }
}

internal class Program
{
    static void Main()
    {
        var nullable = new Item<string?>() { Value = null };
        var notnull = new Item<string>() { Value = "" };
        Console.WriteLine($"nullable is nullable: {nullable.IsNullable()}");
        Console.WriteLine($"notnull is nullable: {notnull.IsNullable()}");
        // Output:
        // nullable is nullable: True
        // notnull is nullable: True
    }
}

It is quite tricky yet good question. I'm afraid that currently what you want to achieve is not possible and you cannot check for explicit ? nullability of generics when generic T is a reference type. And string is a reference type. Your code works perfectly fine when T is a value type:

var nullableString = new Item<string?>() { Value = null }; //IsNullable() true 
var notnullString = new Item<string>() { Value = "" }; //IsNullable() true 

var nullableClass = new Item<SomeClass?>() { Value = new SomeClass{ Id = 1 } }; //IsNullable() true 
var notnullClass = new Item<SomeClass>() { Value = new SomeClass{ Id = 1 } }; //IsNullable() true 

var nullableInt = new Item<int?>() { Value = 2 }; //IsNullable() true 
var notnullInt = new Item<int>() { Value = 3 }; //IsNullable() false

You can read about NullabilityInfoContext in details here, this is a pull request of this feature.

> The nullability for generic type T should be tracked by the user, a
> field declaration List<string?> list or List< string> list will have
> type parameter nullability info but nullability for other List<T> API
> calls should be tracked by the user. For example for list.Add(T item)
> the nullability of item will be evaluated as follows:
>
> 1. T is Nullable if the declaration has ? i.e. GenericType<T?> (even if T is value type it is nullable value type)
>
> 2. T is Nullable for GenericType<T> when nullability context enabled and the concrete type of T is ref type or nullable value type. (In
> this case the nullability of parameter T of List.Add(T item) will be
> Nullable for both List<string> and List<string?> instance, we might
> want 4th nullability state for this scenario)
>
> 3. T is NotNull for GenericType<T> when concrete T is non-nullable value type
>
> 4. T is Unknown for GenericType<T> when nullability context disabled and the concrete type of T is ref type
>
> 5. For open generics the behavior is the same as ref type of T

However, there are no problems to determine explicit nullability of reference types when they are not generics.

var nullabilityInfoContext = new NullabilityInfoContext();
var nullPropInfo = typeof(Foobaz).GetProperty(nameof(Foobaz.NullProperty));
var notNullPropInfo = typeof(Foobaz).GetProperty(nameof(Foobaz.NotNullProperty));

var nullabilityInfo1 = nullabilityInfoContext.Create(nullPropInfo);
Console.WriteLine(nullabilityInfo1.ReadState == NullabilityState.Nullable); //True

var nullabilityInfo2 = nullabilityInfoContext.Create(notNullPropInfo);
Console.WriteLine(nullabilityInfo2.ReadState == NullabilityState.Nullable); //False

public class Foobaz
{
    public string? NullProperty { get; set; }
    public string NotNullProperty { get; set; }
}

NullabilityInfoContext "Provides APIs for populating nullability information and context from reflection members: ParameterInfo, FieldInfo, PropertyInfo, and EventInfo."

It does this by looking at the reflected information of the associated types themselves, and by inspecting additional metadata (some kind of hidden attributes, as far as I can tell) associated with things like properties.

So if you're using a truly Nullable<> generic type, as in DoubleL's example, where int? is literally a Nullable<int>, then at runtime it is known that the Value property returns a Nullable<int>.

But that doesn't work for reference types like String:

> Nullable reference types aren't new class types, but rather annotations on existing reference types. The compiler uses those annotations to help you find potential null reference errors in your code. There's no runtime difference between a non-nullable reference type and a nullable reference type.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-reference-types#nullable-references-and-static-analysis

So what about the attributes on properties? Well, that's tied to the property, and not the generic type. If you included enough information on the class for it to know that the generic type could not be null, it would look at the property's signature itself to decide whether the property is nullable. For example:

public class Item<T>
    where T : class // This says T should not be null
{
    public required T Value { get; init; } // Not Nullable
    public required T? Value2 { get; init; } // Nullable

But otherwise, it has to assume that if T is a reference type, it can always be null. There's simply not enough data available at runtime to do what you're trying to do. There is no difference at runtime between an Item<string> and an Item<string?>.

Your solution is correct.

The problem there is that, type "string" is a reference type which it can be null by-default. In other words, there is no difference between "string" and "string?", both will be nullable.

If you try to run your example with:

var nullable = new Item<int?>() { Value = null };
var notnull = new Item<int>() { Value = 0 };

will work fine.