Add System.Enum<TUnderlying> and allow it as a generic constraint for enum types

[CodeSetting]

While the addition of where T : Enum was a most welcome enhancement to the C# language, it could be more powerful.

If the simulated inheritance where more like enum : T ⟶ System.Enum<T> where T : IBinaryInteger<T> ⟶ Enum, this would support some more powerful possibilities.

Currently, if I want to have a generic method that acts on some values shared between multiple types of enum, I'm forced to incur boxing overhead that is not strictly necessary.

Consider the following enum types:

enum SharedEnum : int { SharedGood, SharedBad }
enum MyEnum : int { SharedGood = SharedEnum.SharedGood, SharedBad = SharedEnum.SharedBad, Private }

when directly accessed, no boxing (via object) is required:

MyEnum myEnum = MyEnum.SharedGood;
if ((int)myEnum == (int)SharedEnum.SharedGood) doSomething();

now, consider the case where I want to work with generic constraints, while I can do the following, the boxing (via object) of (int)(object)theEnum is less than ideal.

void SharedAction<TEnum>(TEnum theEnum) where TEnum : Enum
{
  if ((int)(object)theEnum == (int)SharedEnum.SharedGood) doSomething();
}

With my proposed solution, in the following ((int)theEnum == (int)SharedEnum.SharedGood)), it might be possible to avoid the intermediate boxing to (object), and it would more closely resemble the direct access.

void SharedAction<TEnum>(TEnum theEnum) where TEnum : Enum<int>
{
  if ((int)theEnum == (int)SharedEnum.SharedGood) doSomething();
}

It might also allow enum to more broadly participate in the features provided by IBinaryInteger. Although, extending this behavior to include these additional features might introduce unintended consequences.

Thank you for taking the time to read this and for your consideration.

[TahirAhmadov]

I think if you add struct to the where, it shouldn't box, but i may be wrong

[333fred]

No boxing occurs even without the where, the runtime understands that cast and elides it from the specialized method.

[CodeSetting]

Thank you for taking the time to read the proposal. Unfortunately, neither suggested behavior works.

@TahirAhmadov Adding the struct constraint does not appear to resolve the issue. An intermediate boxing via object still seems to be required. See log at end of response.

@333fred It also does not work without the struct constraint, still requiring the same intermediate boxing. See following log.

The following is a log from the C# interactive window. As you can see, with the intermediate boxing everything is good. Without it, pursuing either of the suggested options results in a compile-time type error.

> void SharedAction<TEnum>(TEnum theEnum) where TEnum : Enum { if ((int)(object)theEnum == (int)SharedEnum.SharedGood) doSomething(); }
> void SharedAction<TEnum>(TEnum theEnum) where TEnum : struct, Enum { if ((int)theEnum == (int)SharedEnum.SharedGood) doSomething(); }
(1,74): error CS0030: Cannot convert type 'TEnum' to 'int'
> void SharedAction<TEnum>(TEnum theEnum) where TEnum : Enum { if ((int)theEnum == (int)SharedEnum.SharedGood) doSomething(); }
(1,66): error CS0030: Cannot convert type 'TEnum' to 'int'

[333fred]

As you can see, with the intermediate boxing everything is good.

I did not say that you can omit the object cast from your C#. I said the JIT understands that cast and elides it from the result. No boxing occurs at runtime, as you would see if you looked at the resulting ASM.

[colejohnson66]

Is this even possible without a recompilation of literally everything? Because right now, every enum inherits from Enum, not Enum<U>. Or is this proposal saying where T : Enum<U> is to be syntax sugar that the JIT would understand?

[TahirAhmadov]

To be honest, I don't quite understand why "inserting" a type into the inheritance chain would break things. Can someone give an example of an operation which would be affected by such a change?

[colejohnson66]

It won’t “break” anything, but, as I said, it will fracture the ecosystem.

Consider using a library compiled against .NET <=9 while your app uses something newer. Your app/library’s enums would implement the hypothetical IEnum<T>, but nothing in the library would.

System.Enum itself probably could implement interfaces (implementing interfaces on BCL types is “safe”), but enums themselves can’t without JIT magic.

[TahirAhmadov]

Personally I don't view this as a huge problem. Yes those older enum types act differently, but this is fundamentally a temporary problem and one which developers can navigate. It is, after all, a new feature. Those who need it will simply rebuild (or politely ask the library authors to rebuild) needed libraries, or simply wait some time.

I actually thought about a potential reflection break: BaseType property now returns something different than before.

[HaloFour]

Would it "reset" the ecosystem if it was something the runtime silently applied and all enums now extended from Enum<T> where T is the underlying type?

However, even if that was possible I question the value of doing it. Being able to cast from the underlying type to the enum and back in a generic context doesn't make a lot of sense to me, and most math operators really don't apply to enums most of the time. IMO, an enum really shouldn't be treated as a number, that's just an implementation detail.

[colejohnson66]

It's possible the JIT could automagically implement IEnum<TUnderlying> on enums, or the compiler could lower where T : IEnum<...> as some modreq (replacing casts with Unsafe.BitCast), but neither seems "worth it" IMHO.

[jrmoreno1]

Allow enums to implement an interface, and then have IEnum<Underlying>?