Proposal: Enum flag operation shorthand

[rpetz]

I would like to propose a shorthand way of handling enum operations to keep the resulting code less wide and more concise. I normally am not one to step into this realm of syntactic sugar, but this one I feel warrants consideration.

When performing and or or operations with enum flags it can get out of hand quickly. For example:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Struct | AttributeTargets.Enum, AllowMultiple = true)]

Not only is this just extremely redundant code to both read and process mentally, it also promotes the next person reading the code to skim it since it isn't very tidy. Not to mention (at least, in the above example) this promotes making attributes multi-line, which has it's own cons in of itself. Instead, this is what I propose:

Example 1 - Usage in an attribute (NOTE: Same as above example)
Currently:
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Struct | AttributeTargets.Enum, AllowMultiple = true)]

Originally Proposed:
    [AttributeUsage(AttributeTargets: Class | Property | Field | Struct | Enum, AllowMultiple = true)]

Revised Proposal:
    [AttributeUsage(new AttributeTargets(Class | Property | Field | Struct | Enum), AllowMultiple = true)]
---

Example 2 - Basic construction
Currently:
    var someValue = MyEnum.First | MyEnum.Second | MyEnum.Third;
    var isSecondValue = someValue & MyEnum.Second;

Originally Proposed:
    var someValue = MyEnum: First | Second | Third;
    var isSecondValue = someValue & MyEnum.Second;

Revised Proposal:
    var someValue = new MyEnum(First | Second | Third);
    var isSecondValue = someValue & MyEnum.Second;

Breaking it down it would be of the following components:

new [Enum Type Name]({ [Value 1] [Bitwise] [Value 2] ... [Bitwise] [Value N] });

Original Proposal - kept for posterity

The operator I am proposing is `:` - The presence of this operator immediately following an Enum type is what would signify the beginning of the shorthand. Since this shorthand will always result in an object of the declared enum's type, there is no need for any kind of character to signify the end of the shorthand. Instead, the end should be whenever any other object reference would normally end. For example:

Since it is possible currently to compile new MyEnum() (which would return the default value for that enum) the goal of this proposal would be to allow creating a new enum object while defining a different value from default. The enum's members would be available within the parentheses as local type-inferred members.

Example 3 - Usage in an `If` statement
Currently:
    var someValue = MyEnum.First;
    var someOtherValue = MyEnum.Second;
    if (someValue == MyEnum.First | MyEnum.Second && ...)
    { ... }

Originally Proposed:
    var someValue = MyEnum.First;
    var someOtherValue = MyEnum.Second;
    if (someValue == MyEnum: First | Second && ...)
    { ... }

Revised Proposal:
    var someValue = MyEnum.First;
    var someOtherValue = MyEnum.Second;
    if (someValue == new MyEnum(First | Second) && ...)
    { ... }

---

Example 4 - Ternary operations
Currently:
    var someBoolean = true;
    var result = someBoolean ? MyEnum.First : MyEnum.First | MyEnum.Second;

Originally Proposed:
    var someBoolean = true;
    var result = someBoolean ? MyEnum.First : MyEnum: First | Second;

Revised Proposal:
    var someBoolean = true;
    var result = someBoolean ? MyEnum.First : new MyEnum(First | Second);

If another local member outside of the parentheses has the same identifier as an enum value that is being referenced inside of the parentheses then an ambiguous reference error should be thrown. For example:

Example 5:
    public class MyClass
    {
        public MyEnum KnownValue { get; }

        public MyClass(MyEnum val)
        { KnownValue = val; }

        public void MyMethod(MyEnum providedValue)
        {
            if (providedValue == new MyEnum(KnownValue | Boat)) // NOTE: This accesses the property `KnownValue` inside of the shorthand
            { ... }
        }
    }

Example 6:
This should throw an ambiguous reference error due to the 'Vehicle' identifier:
    public class MyClass
    {
        public int Vehicle { get; set; }

        public void MyMethod(MyEnum providedValue)
        {
            if (providedValue == new MyEnum(Boat | Vehicle))
            { ... }
        }
    }

Please let me know your thoughts - I genuinely feel this would be a big improvement to the language and would make reading these operations MUCH easier and much more concise.

EDIT - Syntax change from original proposal

@CyrusNajmabadi Brought up that ternary operations would introduce ambiguity into the code - I am ammending this proposal to introduce a slightly different syntax that (as far as I can tell) should resolve that ambiguity:

new MyEnum(Boat | Vehicle)

My reasoning behind this is that it is currently possible to call an empty constructor off of an enum and have it return the default value for that enum (though it isn't common in practice). This would allow the enums members to be clearly defined as locally referenceable in just that single expression, while making it clear what the developer's intentions were with using this syntax (plus I would imagine it's a tad less difficult to implement in this way as a bonus haha). The use of the new keyword feels correct for the context and already established language paradigms - but I would also say it could be eliminated if the goal is to make code more concise - e.g. if (providedValue == MyEnum(Boat | Vehicle)

I have updated all the above examples to reflect the new syntax instead.

[jnm2]

There's a proposal already championed which would cover not only enum members but also static members on other types: #2926

[rpetz]

I have seen this proposal, however there is a slight difference between that and this which I feel is important:

The readability of including the target type in the expression is extremely valuable to me (and I would say a large majority of developers too).

I am all for target-typing all the things, but it can also be extremely unreadable to someone else viewing someone else's code that isn't specifying the type. For instance (though contrived):

var result = new SomeClass(Boat | Vehicle);

When I read that I don't immediately think "that is an enum of type MyEnum" - my first thoughts will be that we are ORing together two local properties in the class called Boat and Vehicle. If I'm just reviewing the code it does not tell me that those are two values of the enum MyEnum, which means I may not put two and two together that there is an enum defining types of motorized vessels for use in other places. If I were coming in later to try and understand the code this would be WAY more beneficial to me:

Initial proposal:
var result = new SomeClass(MyEnum: Boat | Vehicle);

Updated idea from my comment here

var result = new SomeClass(MyEnum.: Boat | Vehicle); 
var result = new SomeClass(MyEnum(Boat | Vehicle)); <- I prefer this

Sometimes there is a benefit to including the type - so I would say this is a different proposal from the referenced one (which I actually also support for other use cases than this one). Options are always welcome, and I feel that this would be a highly used alternative to the referenced proposal.

[rpetz]

I updated the original discussion with an edit addendum to note this new syntax. Hopefully it clarifies my case for why this isn't necessarily related to #2926 in spirit haha

[jnm2]

The readability of including the target type in the expression is extremely valuable to me (and I would say a large majority of developers too).

So, under the target-typed name lookup, why not do this when you feel the enum name aids in readability?

[AttributeUsage(AttributeTargets.Class | Property | Field | Struct | Enum, AllowMultiple = true)]

[rpetz]

@jnm2 Hmm, it appears I did not recognize you could mix your target-typing with direct typing in that proposal

[CyrusNajmabadi]

NOte: this woudl be challenging in a few contexts.

First, Dictionary-Literals (part of the collection literals spec) uses K : V to indicate a key-value pair.
So if you had [MyEnum : Boat | Vehicle] that is now syntactically ambiguous.

Second, : is used in ternary expressions. So the following becomes harder to reason about : x ? someValue == MyEnum : Boat | Vehicle
Is that parsed as x ? (someValue == MyEnum) : (Boat | Vehicle) or as x ? someValue == (MyEnum : Boat | Vehicle).

[rpetz]

Fully agreed on the ambiguity of the : operator - what if we made it key off of the . operator (I mean it does signify that the proceeding contains members from the type to the left of the . operator)

MyEnum.: Boat | Vehicle

OR it could even be enclosed in parentheses to wrap the expression:

MyEnum(Boat | Vehicle)

I actually rather like this idea as it is more readable. Since new MyEnum() would return the default value from the enum it actually makes sense that you could overload the 'constructor' with a different value during this singular expression.

[rpetz]

I added an edit addendum to the original discussion regarding this. The more I have thought on your comment and my response the more it actually feels like the correct kind of syntax for the goal of this proposal.

[rpetz]

I also wanted to share this:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Struct | AttributeTargets.Enum, AllowMultiple = true)]
^^^
166 characters - 81 characters of which are repeating the enum type's name 'AttributeTargets`

[AttributeUsage(new AttributeTargets(Class | Property | Field | Struct | Enum), AllowMultiple = true))]
^^^
104 characters - 17 characters of which are a single reference to the enum type's name 'AttributeTargets'

There is a major advantage to this for sure