Issue with nullable Enum in generic method

[miroslav22]

There appears to be a bug in the compiler when passing a nullable enum type with contraint of Enum:

`
namespace Test
{

public class Program
{
    [Flags]
    public enum FlagsEnum
    {
        Flag1 = 1 << 0,
        Flag2 = 1 << 1,
        Flag3 = 1 << 2,
    }

    static bool GetFlag<TEnum>(TEnum? field, TEnum flag) where TEnum : Enum => field?.HasFlag(flag) == true;

    public static void Main()
    {
        FlagsEnum? nullable = null;

        var result = GetFlag(nullable, FlagsEnum.Flag1);
    }
}

}
`
The line:

var result = GetFlag(nullable, FlagsEnum.Flag1);

CS0312 The type 'Test.FlagsEnum?' cannot be used as type parameter 'TEnum' in the generic type or method 'Program.GetFlag(TEnum?, TEnum)'. The nullable type 'Test.FlagsEnum?' does not satisfy the constraint of 'System.Enum'.

Seems to be an incorrect compile error.

NET 6.0 / VS 17.2.0

[ufcpp]

where TEnum : struct, Enum

[PathogenDavid]

You need to constrain TEnum to struct. (SharpLab)

static bool GetFlag<TEnum>(TEnum? field, TEnum flag)
    where TEnum : struct, Enum
    => field?.HasFlag(flag) == true;

[miroslav22]

Ah that's great, thanks. Why is this out of interest? Just a quirk of the compiler?

[PathogenDavid]

This is a quirk of how nullable reference types interact with generics. (You get a hint in the form of the warning you get when nullable reference types are disabled.)

Without the struct constraint, System.Enum is valid for TEnum, and System.Enum is a reference type.

When a generic type can be either a reference type or a value type, the ? only applies when it's a reference type.

Nullable reference types don't affect the type system. IE: As far as the runtime cares object and object? are the same thing.

Internally a nullable value type is just syntactic sugar for System.Nullable<T>. IE: int? is a different type entirely from int. So in a generic context, when TEnum can only be a struct, TEnum? actually compiles down to System.Nullable<TEnum>. (You can see this here -- compare to this version without the constraint).

Because of these differences, there isn't a way for the compiler to represent a method that takes a nullable reference T or a nullable value T. It has to be one or the other.

[jnm2]

Same issue as in #6004.