The enum generic constraint does not function as expected. For nullability analysis, it is not even able to detect it as non-nullable by default.

[egvijayanand]

Enum is considered a reference type based on its definition and is not treated as a special value type that is non-nullable by default.

[mburbea]

To get the most use for the constraint you can use both.

public static void Show<T>() where T: struct, Enum
{
}

[333fred]

The analysis is correct. Enum is a valid type argument:

using System;

M<Enum>(); // Prints true

void M<T>() where T : Enum => Console.WriteLine(default(T) is null);

[jnm2]

but C# doesn't allow this definition where T : enum

This was mentioned as something that could be done later: https://github.com/dotnet/csharplang/blob/main/meetings/2018/LDM-2018-01-03.md#constraints

And I think sure, this sounds good. But given the ease of typing Enum, struct, do we really want folks to stop working on other language features and add where T : enum?

[egvijayanand]

Rather designs should be complete (or near to completion) and not provide workarounds like include struct. When a struct is included, it loses its special meaning.

It's not only nullability, casting to integral type is also not supported for this generic Enum constraint.

T t = default;
T t2 = (T)1;  // Can't assign a numeric literal too
var value = (int)t; // Won't work

[timcassell]

That wouldn't work for an enum constraint, either. Enums can be backed by byte or long, you can't just blindly cast to int on a generic enum.

[333fred]

Rather designs should be complete (or near to completion) and not provide workarounds like include struct. When a struct is included, it loses its special meaning.

The design is complete. An enum is nothing more than a struct that inherits from System.Enum. No additional meaning would be provided by allowing you to say where T : enum, it would just be another way of stating the same thing.

[egvijayanand]

That wouldn't work for an enum constraint, either. Enums can be backed by byte or long, you can't just blindly cast to int on a generic enum.

You people are taking it literally. They're just examples.

The underlying conversion should handle those and if they're incompatible, it'll result only in a data loss and it's applicable even for numeric types now.

[CyrusNajmabadi]

Importantly, even if there was some hypothetical 'where T : enumfeature, it wouldn't now makeT t = (T)1;work, or(int)t` work.

[egvijayanand]

Rather designs should be complete (or near to completion) and not provide workarounds like include struct. When a struct is included, it loses its special meaning.

The design is complete. An enum is nothing more than a struct that inherits from System.Enum. No additional meaning would be provided by allowing you to say where T : enum, it would just be another way of stating the same thing.

Definitely not. Though Enum is a struct type, it has some unique characteristics.

If the struct constraint itself is enough, then why another explicit constraint in the name of Enum?

[CyrusNajmabadi]

The underlying conversion should handle those

There is no underlying conversion. That's the point.

it'll result only in a data loss and it's applicable even for numeric types now.

It is not applicable to numeric types now. You can contrain to things like INumber<T>, but that doesn't mean you can cast to (int). You are conflating runtime casts and compile time conversions.

[jnm2]

Perhaps it's time for a built-in analyzer for where T : Enum if you forget to include struct?

[egvijayanand]

The explicit numeric conversions would have been seamless in a generic Enum if the following had been included as part of the implementation as it translates to just a static method call T.op_Explicit, with T : Enum as its constraint, this would have invoked the method in the base class Enum like Enum.op_Explicit.

Bar bar = new(); // A subclass of Foo and not Foo
var num = (int)bar; // Explicit conversion defined in Foo but works for the subclass of Foo - akin to user-defined enums
Console.WriteLine(num);

// We can add more integral overloads to support other data types
public class Foo // Replace Foo with Enum and try as I can't write a partial declaration for a BCL type
{
    public static explicit operator int(Foo foo)
    {
        var enumType = foo.GetType();
        //return Enum.TryParse(enumType, foo.ToString(), out var result) ? Convert.ToInt32(result) : 0;
        return 100;
    }

    public static explicit operator long(Foo foo)
    {
        var enumType = foo.GetType();
        //return Enum.TryParse(enumType, foo.ToString(), out var result) ? Convert.ToInt64(result) : 0;
        return 100;
    }
}

public class Bar : Foo;

[egvijayanand]

It's just a prototype and with proper analysis, we can write better methods to achieve this.

[CyrusNajmabadi]

If you agree ok with that level of cost and complexity, it can be provided with extension methods. If it were to be part of the language/runtime it would very realistically need to be an efficient instruction.