Proposal: The ability to superset enums

[DerpMcDerp]

We can derive from classes, we should be able to superset enums. e.g. the compiler should transform:

enum TypeCodeEx : TypeCode {
// numbering still starts at 0, not where TypeCode left off
    TimeSpan = 17
}

// There should be an implicit conversion from TypeCode to TypeCodeEx
var res = true ? TypeCode.Empty : TypeCodeEx.Empty;
// res is deduced to TypeCodeEx

to:

[EnumFrom(typeof(TypeCode))]
enum TypeCodeEx : int /* TypeCode's underlying type */ {
    TimeSpan = 17,

// all the names from the underlying enum get pasted in:
    Empty = TypeCode.Empty,
...
    String = TypeCode.String
}

var res = true ? (TypeCodeEx)TypeCode.Empty : TypeCodeEx.Empty;

[alrz]

If those enums were in the same assembly why even you would do that? If they weren't, what's the point? I think you use enums to actually restrict the possible values, right?

[bondsbw]

Subclassing implies the superset enum could be substituted in all locations that the base enum is allowed. This isn't really a goal of enums today, so third party libraries would at best fallback to a default behavior and many would just crash or end up in an undefined state.

Supersets via discriminated union would not allow substitution, so I favor that mechanism over subclassing enums.

[DerpMcDerp]

Read the proposal more closely. It's about "superclassing" enums rather than "subclassing" them i.e. the "base" can be assigned to "derived" rather than the other way around (the polar opposite of how subclassing works). It can't lead to any crashes since it's guaranteed to be a subset.

[bondsbw]

@DerpMcDerp The colon : inheritance operator is used to subclass, not superclass. Reversing that relationship for enum is quite confusing; someone used to C# would assume they could substitute TypeCodeEx for any TypeCode. I suggest reworking that aspect of the proposal.

[temporaryfile]

Let me explain an expansive real world use for enum inheritance that I have actually run into: Win32 interop. You want strong typing without blind casting, mostly to guide Intellisense and prevent all the mistakes you'd be making if you used C++ instead.

First example is kernel object security flags. The base type would have values like GENERIC_WRITE or GENERIC_READ. But derived types would include values like DIRECTORY_QUERY or TIMER_MODIFY_STATE. You don't have to typecast or overload anything if a [DllImport] such as CreateFile() only wants the base enum type.

Second example: Win32 message IDs. There is a base system set, but then applications and custom windows expand the numbering space on their own beyond WM_USER and WM_APP.

Then you have Win32 window style flags, window class flags, and on and on.

[bondsbw]

@playsomethingsaxman [Flags] enums are a bit of a different animal. They are essentially used as a condensed set of Booleans. The following are effectively equivalent (from C#, not considering P/Invoke):

[Flags]
enum AccessEnum : uint
{
    GENERIC_WRITE = 0x40000000,
    GENERIC_READ = 0x80000000
}

AccessEnum access = ...;
...

if ((access & AccessEnum.GENERIC_WRITE) == AccessEnum.GENERIC_WRITE) { ... }
if ((access & AccessEnum.GENERIC_READ) == AccessEnum.GENERIC_READ) { ... }

class AccessClass
{
    public bool GENERIC_WRITE;
    public bool GENERIC_READ;
}

AccessClass access = new AccessClass();
...

if (access.GENERIC_WRITE) { ... }
if (access.GENERIC_READ) { ... }

For flags which are used as flags are designed to be used, with & comparisons, I think subclassing makes sense. Just as subclassing AccessClass and adding a Boolean shouldn't affect anything using the base class, adding a flag to AccessEnum should not affect any existing usage either.

But that's not true for non-[Flags] enums. The following method would break assumptions and could introduce buggy behavior if you substituted a subclass of RgbColor:

enum RgbColor
{
    Red,
    Green,
    Blue
}

public string GetColorValue(RgbColor color)
{
    switch (color)
    {
        case RgbColor.Red:
            return "FF0000";
        case RgbColor.Green:
            return "00FF00";
        case RgbColor.Blue:
            return "0000FF";
    }

    // Don't expect this, ever... it can't happen
    return "undefined";
}

Oh but it can happen, and with subclassing it is more likely.

So [Flags] subclassing is OK but not normal enums. Even so, the only gain I see is in interop scenarios. It's much more straightforward to use a class or struct of Booleans if the type is only used in .NET code.

[temporaryfile]

The switch statement you use on RgbColor can already be broken: (RgbColor)1234. It's a matter of being "likely" as you said. The topic of what should and shouldn't constitute an integer constant is too vast to try to measure and contain.

I use interop as a frequent example because it is a subclass of an important category: speed. Everything is eventually a leaky abstraction when you're coding for speed. But that's for the app/framework developer to decide, not the language developer. Worrying about that switch statement is like Stream.Read() worrying that someone is encoding extra information in the count parameter. At some point the developer has to behave; everything can be broken.

[Flags] is just used by the debugger to correlate multiple bits to multiple identifiers. But you can create enum methods and call them from [DebuggerDisplay] for MUCH richer information, like displaying rogue bits that aren't part of the enum (for Win32 error codes I even P/Invoke FormatMessage). So what then is [Flags] at all? Like traffic laws in NYC: a hint.

P.S. Why do we only have Enum.HasFlag() when there are x86 instructions like BT (we need enum intrinsics BAD)?

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.