Enum types should fit bitwise operator generic type constraint

[anranruye]

Intuitively an enum type can be used as the type T in the following code, but exactly not.

        public static T Or<T>(T a, T b) where T : IBitwiseOperators<T, T, T>
        {
            return a | b;
        }

Of course we know that we can not explicitly implement any interface on an enum type, but obviously enum types implement the IBitwiseOperators interface naturally.

More code is here:

    internal class Program
    {
        public static void Main(string[] args)
        {
            MyEnum a = MyEnum.A;
            MyEnum b = MyEnum.B;
            var c = Or(a, b); // doesn't work
            // the following statements are ok
            var d = a & b;
            d = a | b;
            d = a ^ b;
            d = ~a;
        }

        public static T Or<T>(T a, T b) where T : IBitwiseOperators<T, T, T>
        {
            return a | b;
        }

        enum MyEnum : int
        {
            A = 1,
            B = 2,
            C = 4,
        }
    }

[bachratyg]

Related
dotnet/runtime#73579 (comment)
dotnet/roslyn#67905

[TahirAhmadov]

I think this is a runtime request, not a C# request.

[bachratyg]

See link above

This would likely require a combination of runtime and language changes to support, but it needs language buy off before anything could be done [issue closed]

[BlinD-HuNTeR]

I believe there is a way to implement this proposal without runtime changes:

First of all, IBitwiseOperators contains only static abstract members, and such members may only be invoked through a generic type parameter, which means that we don't need to worry about "casting" an enum to IBitwiseOperators at runtime.

Therefore, one way to implement that, is to simply have the compiler use the underlying enum type as type parameter!

In other words, whenever you call Or<MyEnum>, the compiler will happily accept it at design time, as if MyEnum implemented IBitwiseOperators natively. But when you compile the project, it will instead emit a call to Or<int>, casting arguments and return type as necessary.

Of course, one consequence of that, is that if Or<T> ever does typeof(T), it will return typeof(int) instead of typeof(MyEnum). But who cares?

[CyrusNajmabadi]

@tannergooding if you feel this is worthwhile.

[bachratyg]

The runtime issue linked above (closed and locked) can be repurposed, it's about the same thing. Or should there be a new one?

[Thaina]

@tannergooding I think unlocking this feature would add even more benefit that we could have enum generic constraint, allow enum to implement interface, allow function declaration in enum and so on

public interface ISuccessAble
{
    public bool IsSuccess { get; }
}

////////

public enum StatusCode : ISuccessAble
{
    Success = 200,
    Cached = 201,
    NotFound = 404,

    bool ISuccessAble.IsSuccess => this == StatusCode.Success || this == StatusCode.Cached; // must be explicit?
}

////////

public static void DoSomething<E>(E status) where E : enum,ISuccessAble
{
    if(!status.IsSuccess)
    {
        MyCustomLogger.LogError("Status Failed : " + status);
        return;
    }

    MyCustomLogger.Log("Status Success : " + status);
    DoSomeOtherThingIfSuccess();
}

DoSomething(StatusCode.NotFound);

[tannergooding]

@Thaina, much of that is already possible via extension methods.

The only thing that isn't trivially possible is implementing interfaces, but I'm not sure that is a significant need.

With extension everything, you can even reasonably define extension operators for all interfaces and simply use if (sizeof(T) == sizeof(int)) and similar checks to find the right integer type to bitcast to so you can do the bitwise operation and everything works as expected.

[Thaina]

much of that Yes, but not all

The point is not just extension of one type, but the generic function of the enum type that has the same signature. Which I think extension everything still not covered

I mean, the DoSomething function is not just accept StatusCode. But it can receive any enum type that define IsSuccess function

Which extension everything still not cover this use case. The generic function cannot know that which enum was extending to support IsSuccess without it defining signature such as implementing same interface

[tannergooding]

Much of that is something that isn't typically needed for generic code and which have better alternatives available.

Implementing a type system change like this is expensive and needs the right justifications. It also needs to be common enough that it will likely have significant impact.

I don't believe the scenario given above gives that justification, particularly not given the alternative designs, practices, and things you can do to mitigate or workaround the issue altogether.