Enums & generic math

[trejjam]

Background and Motivation

I was hoping that with static abstract interfaces, there would be a possibility to use generic constraints on Enums. It's useful e.g. for flag enums to set/unset a flag. Unfortunately, the compilator is not happy about the following code. Technically Enums are numbers, so in my opinion, it should be allowed.

Proposed API

using System;
using System.Numerics;

var type = typeof(Generic<EEnum>);
Console.WriteLine(type);

[Flags]
public enum EEnum {
  A=1,
  B=2,
}

public class Generic<TEnum>
where TEnum : struct, Enum, IBitwiseOperators<TEnum, TEnum, TEnum>
{
  public TEnum BitOr(TEnum first, TEnum second) => first | second;
}

Produced error

error CS0315: The type 'EEnum' cannot be used as type parameter 'TEnum' in the generic type or method 'Generic<TEnum>'. There is no boxing conversion from 'EEnum' to 'System.Numerics.IBitwiseOperators<EEnum, EEnum, EEnum>'.

[myblindy]

Technically Enums are numbers

Short story. Profiling allocations in my code the other day I noticed a few tens of thousands of allocations per second coming from Enum.HasFlag. My understanding is that is because that function has to box the enum it's called on to test against the other enum. So I tried to use generic math to write a generic version, and of course that didn't work, because enums don't follow generic math interfaces.

So I tried a few different things, but the main alternative (casting to a number and trivially implementing the function by hand) ran into the issue of what number? Specifically, my enum is being source generated in an ECS implementation, and as you get more and more components the enum type increases in size (uint ,ulong, UInt128). My mind went immediately to source generating a custom Enum.HasFlag for enums, but source generating on top of source generation isn't really supported. Maybe I could write some generic function that does the test based on byte size gotten from reflection and assign it to a generic delegate to forward my test to. In the end it got too complicated and I just tested for it with a basic and.

So to sum things up, the main reason why generic math is extremely attractive for enums is two fold:

1. The existing implementations of pretty much every enum function is extremely, extremely inefficient, specifically because they're built on boxing values. This is unacceptable for a basic value type in 2023.
2. The underlying integer type of the enum isn't known generically, it can be anything from 1 to 16 bytes. The compiler however knows exactly what it is and can allow generic math to work on it correctly and efficiently.

[CyrusNajmabadi]

@stephentoub I thought that ENum.HasFlag was already optimized?

[stephentoub]

It is in .NET Core in optimized code. If you're measuring startup allocations, you might still be looking at tier 0 / unoptimized code.

[tmat]

One of the use cases in Roslyn:
https://github.com/dotnet/roslyn/blob/main/src/EditorFeatures/Core/EditorConfigSettings/Data/EnumFlagsSetting.cs#L42-L59

Here we want a generic code that can and/or integer based flags enums.

[tmat]

Also wondering if the following generic specialization can be made possible:

class OptionValueParser<T>
{
    public bool TryParse(string str, out T value)
    {
        value = default;

        if (typeof(T) == typeof(int))
        {
            if (int.TryParse(str, out var intValue))
            {
                value = (T)(object)intValue;
                return true;
            }

            return false;
        }

        if (typeof(T) == typeof(string))
        {
            // ... 
        }

        // ...

        if (typeof(T).IsEnum)
        {
            if (Enum.TryParse<T>(str, out var enumValue)) // error: The type 'T' must be a non-nullable value type
            {
                value = (T)(object)enumValue;
                return true;
            }

            return false;
        }

        return false;
    }
}

[tannergooding]

@tmat, sounds like you want dotnet/csharplang#6308

[tmat]

@tannergooding Yes, provided that typeof(T).IsEnum is recognized and implies T : Enum, struct

[jcouv]

As far as I can tell from the thread, the compiler is behaving by-design with regards to current language rules. So I'll convert this issue to a discussion.