[API Proposal]: Please add a new enum-sugar

[RioMcBoo]

just look here please

dotnet/core#9802 (comment)

[EgorBo]

@RioMcBoo please use the API Proposal template and describe how is it any different from #69262

[huoyaoyuan]

Referring to original issue:

Judging by the policy, which implies support for old code, there will never be changes in this direction. Because this type is unique and will always be used in the code.

Old frameworks are shipped and invariant. Any api-level feature has to go to new version.

Language feature (for C# or F#) can be applied to old frameworks. However, the generic participation of enums are not owned by languages, which blocks custom-defined generic operation. See #20008 and #112819.

[RioMcBoo]

@RioMcBoo please use the API Proposal template and describe how is it any different from #69262

Referring to original issue:

Judging by the policy, which implies support for old code, there will never be changes in this direction. Because this type is unique and will always be used in the code.

Old frameworks are shipped and invariant. Any api-level feature has to go to new version.

Language feature (for C# or F#) can be applied to old frameworks. However, the generic participation of enums are not owned by languages, which blocks custom-defined generic operation. See #20008 and #112819.

I can't describe in detail what needs to be done, because I'm not very familiar with the internals of dot net. I also can't make changes to the code and post it as a pull request.

But I can describe it. And the gist is to understand what enum is and what association goes hand in hand with it:

1. enum is not an alias of type int, byte or any other, it is a full-fledged wrapper type that should include all the properties of the underlyingtype and be equivalent to it in everything, have the ability to implicitly & explicitly cast to the underlyingtype. But at the same time, the enum type declaration should allow us to express what specific underlyingtype values ​​we expect to have inside. Make the code more understandable and expressive. In all cases of enum usage, we can get by with using its underlyingtype, but the problem is where to store information about how we evaluate this or that underlyingtype value (in comments, keep in mind, in the documentation, in the type description)

2. We could say - that enum can have any type inside as an underlyingtype and is literally an enumeration of possible variations of values ​​of this type. (if it were possible to implement this - this would be exactly what is required, but historically it turned out that this was mainly used at a low level of programming and underlyingtype is usually base types)

Why does the current enum raise many questions and problems? Because the developers initially decided that in C# everything is so object-oriented and everything is so high-level that none of these properties are needed by the programmer. Here's how it was (roughly):

• programmers could create enum types to describe what they expect to see in the underlyingtype value and what they associate it with. They could output the names of these values ​​in text form. They could Serialize and Deserialize these values. (this was not enough)
• then they added the ability to perform some mathematical and bitwise operations within the type (this was not enough)
• then they added the ability to perform some mathematical and bitwise operations together with underlying types (it turns out to be unmanaged) (this was not enough)
• then they added the ability to use the enum value as a "default" for function arguments and inside attributes (earlier there was an error that did not allow this, referring to the fact that this type cannot be determined at the compilation stage) (this was not enough)
• recently they added the implementation of interfaces for base types, allowing them to be fully used in generic methods and classes where mathematical operations are required. And naturally, in the current state, enum does not have this ability.

That is, you can see that despite the denial that we do not need enum as it is in C++ - users and programmers increasingly come to the conclusion that we do. And your constant extensions for enum confirm this.

And all because you do not provide the ability to use enum in the way described in points 1 and 2. If this is not implemented, then the meaning of enum is lost.

I am just learning programming and have already encountered many problems that arose due to the lack of points 1 and 2 in full as they are described.

Many programmers simply turn a blind eye to this. They use their own types, use reflections and other ways to get around this. But this does not mean that it should be this way and that this is normal. If people have adapted, it does not mean that everything is fine.

And it was not for nothing that I gave the example of Records. I do not really understand how they work internally, but one thing is clear - I can override some methods, which means that this is something like metaprogramming, when the IDE itself creates code simplifying the user's work according to a given template.

I don't claim that this is the only possible way to implement enum, but my example shows that "theoretically" the user can create an enum themselves and get all the desired properties without using reflections, without unnecessary boxing. But even trying to make my example I encountered the following:

1. I could not fully implement the IBinaryInteger interface because many methods that the base classes implemented were not available for calling via the UI.
2. I am sure that my code lacks serialization capabilities and this is probably difficult to do without reflection (so it required managed runtime code), because here we are not talking about instance fields, but about static type fields.
3. Each time determining this type, I must do a huge pile of work and use AI ASSistant or macros.

I don't know how you can do this, but if you can implement the very idea that enum automatically has the properties of its underlyingtype - this solved all the problems.

If I specify int as the underlying type - I expect that my enum inherits the properties and interfaces of the int type.

If I specify string as the underlying type, I expect my enum to inherit the properties and interfaces of the string type.

A good example of this is:
string.Empty can be interpreted as:

enum MyStrings : string
{
    Empty = "",
    Error404 = "Not Found",
}

enum MyEmployee : Employee
{
    None = new Employee(Person: null, adress: MyStrings.Empty),
    Director = new Employee(Person: new(name: Elon, sex: Sex.Male), adress: "X"),
}

And then everything also will fall into place:
if I use any of the basic types (unmanaged) as the underlyingtype - I can use this enum instance as default for arguments of functions and methods. If I use a class or my own structure as the underlyingtype - I lose this opportunity but retain the ability to fully use the enumeration's instance as the underlyingtype.

And then, if you implement this, we will not need methods such as Hasflag () / HasAnyflag () - we can easily add them using the methods - expansion or generic methods that I also showed in my previous example (see the link above).

I am also sure that all other problems and questions will disappear.

[huoyaoyuan]

There are already plenty of discussions about improving enums. With the current contract and limitation by different subsystems and standards, we can't make any meaningful change that applies to every enum.

If I specify int as the underlying type - I expect that my enum inherits the properties and interfaces of the int type.

This is the spirit of dotnet/csharplang#9223 and dotnet/csharplang#5496 .

If I specify string as the underlying type, I expect my enum to inherit the properties and interfaces of the string type.

This is also related to dotnet/csharplang#5937 and dotnet/csharplang#8804 .

Either way, this will make a new category of type, not the CLR enum.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[RioMcBoo]

I am sorry, I am totally newbie here, and my eng is A2 maximum. The documentation and dotnet terms is not my strength.

[huoyaoyuan]

To be simple, improving enums wouldn't be a simple sugar. It would be a massive change to the type category spans across multiple components.