Const Enums

[panost]

Are entries in the enum definition, that are not actually enum members.

For example:

    enum Color {
        const WhiteStart, // = 0
        White, // = 0
        Snow, // = 1
        GhostWhite, // = 2
        
        // or an attribute [Const] or [Marker]
        const WhiteEnd, // = 2 
        
        Pink, // = 3
        LightPink, // = 4
        HotPink, // = 5
        const PinkEnd, // = 5
        ...
        
        const LastEntry // = the last value of the enumeration
    }

The static methods in Enum, (GetValues,TryParse etc) totally ignore those entries, but intellisense does bring them as valid entries.
Also they do not affect the auto-numbering of any Enum item.
Removing any const entry will have no effect on the auto numbering of any other entry (normal Enum item or const item)

That means that the unitialized normal enum entry that follows a const entry, will have the value of the previus normal entry plus one.
The value if they left unitialized is the value of the previous normal entry or 0 if they are first.

This feature can be further extended in flags enums to support Bitmasks or BitFields, but that will complicate the syntax. I prefer the syntax of bitfields as is in #465 but instead of a struct, the base type to be an Enum

[lillo42]

Are you proposals feature like this ?
dotnet/roslyn#13192

[panost]

@lillo42 No, Look for an example, (the first I found )

https://github.com/dotnet/corefx/blob/2f096d410befd4b348bf0cdf9344cf2221869581/src/System.CodeDom/src/System/CodeDom/MemberAttributes.cs

The entries AccessMask, ScopeMask and VTableMask are not actually part of the enumeration but additional entries that help (through masking in this example) to manipulate MemberAttributes values.

In other enumerations they are entries that mark some section (as in the example I gave above) or used to mark the maximum value of the enumeration (See ProtocolFamily.Max)

The runtime assumes that those are valid enum entries but they are not. They are not supposed to be serialized using their name and TryParse/Parse should fail also. "Max" (for example) is not a valid value for a ProtocolFamily and yet Parse/TryParse will not complain

[jnm2]

The runtime assumes that those are valid enum entries but they are not.

Sure they are. What's wrong with a MemberAttributes mask parameter?

[panost]

The code below doesn't make any sense

new CodeMemberField(typeof(string), "MyField") {
  Attributes = MemberAttributes.VTableMask
}

or when I serialize a Color with a value of Color.White the string "WhiteStart" will be saved

and just to be clear with my intentions, I don't want this so I can introduce some new functionality in an enumeration. Extra (or Marker or Mask) members are already used (or misused) in many enumeration declarations. I want a new specifier that will actually describe the author's intentions.

[jnm2]

The code below doesn't make any sense

It's no different than All flags. You can always find examples of flags that are incompatible with each other. I'm not sure this is a problem.