Champion "Allow `System.Enum` as a constraint" (15.7)

[gafter]

Allows where T : System.Enum

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

See also dotnet/roslyn#262

[TylerBrinkley]

I'm of the opinion that Enum was not allowed as a generic constraint initially in C# due to generic code-explosion as the current .NET runtimes don't share generic code for value types like they do for reference types. With the implementation of corefx#15453 this would be less of a problem as it should cover most use cases for an Enum generic type constraint and internally it would try to reduce this generic code-explosion by limiting usage of Enum as a generic type parameter as much as possible. I'm wondering if something could be done in the runtime to allow types and methods with generic enum type arguments to share code when the enum type shares the same underlying type.

Perhaps another reason Enum was not allowed as a generic constraint initially in C# was due to the potential expectation of users that the bitwise operators would be available on those generic types for flag operations. Implementing these bitwise operators were discussed in roslyn#262 and even before that on Roslyn's CodePlex site and the consensus was that there were issues when trying to implement them in IL due to differing underlying types. This expectation would be mitigated by the implementation of the flag enum operations provided in corefx#15453.

I may be mistaken but I believe removing the explicit filters in the compiler preventing Enum as a generic constraint would allow it to just work as expected as any other class type constraint.

I would love to see this implemented as soon as possible to enable the benefits corefx#15453 would provide. I'd gladly contribute in anyway needed.

[temporaryfile]

Generic constraints make sense with enum inheritance. Example from the future:

public enum WindowMessage
{
    WM_NULL = 0,
}

public enum ListViewMessage : WindowMessage
{
    LVM_FIRST = 0x1000,
    LVM_EDITLABELW = (LVM_FIRST + 118),
}

public static IntPtr SendMessage<TMessageType>(
    HWND hwnd,
    TMessageType Msg = WindowMessage.WM_NULL,
    UIntPtr wParam = default(UIntPtr),
    IntPtr lParam = default(IntPtr))
    where TMessageType : WindowMessage
{
    // [....]
}

[TylerBrinkley]

@gafter & @AnthonyDGreen is there anything myself or the community can do to make this a reality? I'd really like to move forward with corefx#15453 but this seems to be the blocker.

I believe the only code changes needed would be a few line removals in roslyn/Binder_Constraints.cs.

[gafter]

@TylerBrinkley I don't see what aspect of the proposed API would benefit from this.

[TylerBrinkley]

@gafter There are two issues with implementing corefx#15453 now without the generic Enum constraint.

1. Adding the Enum constraint later to enable extension methods would be a breaking change and may not be acceptable. In the proposal I've added the constraint to the existing generic versions of Enum.Parse and Enum.TryParse but that would be a breaking change as noted in this comment. If we can't add the Enum constraint to those two methods it wouldn't be a big deal as all it may mean is an additional type check but for the other methods proposed it would be detrimental as they couldn't be made into extension methods.
2. Even if adding the Enum constraint later is deemed an acceptable breaking change the FlagEnum methods cannot later be promoted to extension methods due to Static using makes extension method promotion a breaking change #665.

[TylerBrinkley]

@gafter or @AnthonyDGreen again I ask, is there anything myself or the community can do to make this a reality?

[TylerBrinkley]

Forgive me but I'm going to continue to spam this request until I get a response.

@gafter or @AnthonyDGreen is there anything myself or the community can do to make this a reality?

[jnm2]

Ditto.