Nested type support for 'enum' types

[tagcode]

Classes, structs, record, interfaces all allow nested types, but enums do not. Would it be possible to add support for 'enum' types also?

public static void Do<T>(T obj) where T : MyEnum.IProperty
{
    if (obj.HasAll(MyEnum.Flag1 | MyEnum.Flag2)) { } // .. do something
}

[Flags]
public enum MyEnum : int
{
    Flag1 = 1,
    Flag2 = 2,
    Flag3 = 4;

    public interface IProperty {
        MyEnum Flags { get; set; }
    }

    public static class Extensions {
        public static bool HasAll(this IProperty enumProperty, MyEnum expectedFlags) => (enumProperty.Flags & expectedFlags) == expectedFlags;
    }
}

[jnm2]

I would also really like to be able to declare methods and properties inside enums.

[TahirAhmadov]

@tagcode I think it's better to have a semicolon after the last enum option and before other members.

[DavidArno]

I don't really see the purpose of this request when such things can already be acheived by flipping the problem on its head and embedding the enum within a static class, eg:

using System;
using static My.Enum;

var e1 = Flag1|Flag2;
var hasAll = e1.HasAll(Flag2);
var hasAny = e1.HasAny(Flag2|Flag3);

var e2 = e1.WithoutFlag3();
var e3 = e1.WithFlag3();

public static class My
{
    [Flags]
    public enum Enum : int
    {
        Flag1 = 1,
        Flag2 = 2,
        Flag3 = 4
    }

    public static bool HasAll(this Enum myflags, Enum expectedFlags) 
        => (myflags & expectedFlags) == expectedFlags;
    
    public static bool HasAny(this Enum myflags, Enum expectedFlags) 
        => (myflags & expectedFlags) != 0;
    
    public static Enum WithFlag3(this Enum myflags) => myflags | Enum.Flag3;
    public static Enum WithoutFlag3(this Enum myflags) => myflags & ~Enum.Flag3;
}

[colejohnson66]

That's not much different than what can be done today:

public enum MyEnum : int
{
    // ..
}

public static class MyEnumExtensions
{
    // ..
}

I'd like to see this requirement dropped. Extension classes have many limitations — the biggest being the lack of properties. In fact, Dotnet's own framework design guidelines state that having methods called GetX and SetX (a la Java) are discouraged in favor of properties, but that's been impossible for 20+ years.

The "best" workaround I've seen (and it's what I use) is to make a struct that contains a single field — it's "index":

public readonly struct MyEnum
{
    internal readonly uint Index;

    private MyEnum(uint index)
    {
        Index = index;
    }

    public bool HasFeatureX =>
        Index >= SOME_CONSTANT;

    // JIT optimizes these as loading a single constant (bit representation of MyEnum == uint), then inlines them
    public static MyEnum ValueA => new(0);
    public static MyEnum ValueB => new(1);
}

But this is a ton of code. It gets even worse, though; Because it's not a real enum anymore, switch expressions and patterns don't support matching on it.

[DavidArno]

That's not much different than what can be done today

I'm not sure I follow you. What I posted is completely legal today. The only limitation on the other examples is that WithFlag3 and WithoutFlag3 have to be methods, not properties. But that is something that hopefully will be addressed should the "extension everything" feature ever be implemented.

[colejohnson66]

Yes. The big limitation is properties. As I mentioned, I'm unaware of any limitation in the IL for this restriction — It seems to be purely a language one. And yes, "extension everything" would help, but it doesn't actually fix the issue; Just hides it by shoving the enum into a proxy type.