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?

[CodeSetting]

@colejohnson66 I would leave the design decisions to those wiser than myself. Personally, I had envisioned adding an intermediate class Enum<T>, which inherits from Enum. Then, I would expect an enum to inherit from the appropriate closure (depending on its underlying type). That said, I'd be equally happy with syntactic sugar or any other compiler magic 😊

[tannergooding]

That would basically "reset" the ecosystem. You'd have 20 years of existing enums that wouldn't work and then everything newer. There's also complexities in that the set of types allowed to derive from System.ValueType are explicitly limited.

This is just a generally complex space and there isn't really a "good" fix, especially not without expensive and complicated runtime changes.

[colejohnson66]

Yes, changing the actual inheritance chain in the IL would fracture the ecosystem — absolutely not. The only possibly viable solution would be the compiler and JIT faking it. Have where T : Enum<U> be syntax sugar for where T : Enum and some modreq attribute. Also replace (int)someT with Unsafe.BitCast<T, int>(someT). Doable, yes, but is it worth the effort? Doubt it.