[Proposal] Flags Enum Initializer

[Chi-TheCookie-Chi]

Currently we have the very handy object and collection initializers but we don't have anything for flags enums which tend to have long names for readability which soon turns into verbosity when specifying multiple flags.
An example of such verbosity is found in the .NET framework: AttributeUsageAttribute attribute which takes AttributeTargets enum flags which is defined for SerializableAttribute attribute as such:
[AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate, Inherited = false)]
Possible fix:
[AttributeUsageAttribute(AttributeTargets { Class, Struct, Enum, Delegate } , Inherited = false)]
or use a pipe instead of commas (though this is inconsistent)
A possible issue to discuss is what to do when the enum doesn't have the FlagsAttribute attribute

[stakx]

@Chi-TheCookie-Chi, I like seeing an issue for this problem because the longwinded flags enum | expressions really are a bit of a pain point. 👍

If you're dealing with flags enums having fairly unique names, you can use using static SomeFlagsEnum to bring the various flags into scope.

using System;
using static System.AttributeTargets;

[AttributeUsage(Method | Property | Field | Constructor)]
class MyAttribute : Attribute { }

This doesn't work so well if you're simultaneously using several flags enums in the same document that have some overlap in their flags' names.

[Chi-TheCookie-Chi]

That is really neat! However, I think the 'initializer' approach is more readable for the use context and less error prone.

[yaakov-h]

#321 might solve this.

[jnm2]

Not sure I like the initializer syntax.

[theunrepentantgeek]

If I read #321 correctly, we'd be able to re-express this (currently legal) code

[AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate, Inherited = false)]

as

[AttributeUsageAttribute(Class | Struct | Enum | Delegate, Inherited = false)]

Which I like very much - it doesn't introduce new syntax so much as just work the way people might expect.

[Chi-TheCookie-Chi]

@yaakov-h Thanks for the link. I researched more on the topic and it seems there are many issues that are related to enum verbosity and I would like to add my input on these issues and related suggestions in an effort to shed some light and get new ideas on the subject.
As for the options in the linked issue:
IsolationLevel = ReadCommitted is a bad suggestion because it:

• looks magical
• is a possibly a breaking change
• is a non issue for non-flag/one flag enums (write one time, readable -the point of scoping)
• Adds burden to the compiler by checking the context and then optionally importing all flags which adds more issues (how to handle different enums with same enum value names?)
• shouldn't work with var
• is not consistent with the type of inferring C# would provide (otherwise we would be able to assign {...} to a span without stackalloc, use var params..etc by now)

I am against the second one since that is a naming conflict which should always result in an error and I don't see why enums should be an exception. Besides, wouldn't that make C# one of the few if not only programming language that has a defined behaviour for naming conflicts?
#330
This is an open issue and the fix is pretty easy.
For a normal enum, the fix is a generic extension method possibly named IsAny(EnumValue) which takes this T tenum, params T[] values and a simple loop/LINQ to check any equality.
For a flags enum, I think a new method should be introduced to .net named HasFlags otherwise you can now (thanks to enum constraint) create a generic extension method with System.Enum constraint and run Enum.HasFlag in a loop on the param args (though it is a bit slow).
#764
is C-ish in nature, similar to the first suggestion a bit and I'd argue that it is an ugly one but: it does fix dotnet/rosyln#20605, it is not that magical for C dev and if the user forgets to add a dot then an error would occur which is only natural.
It is also useful in switch cases because it is not possible to conflict with other variables and also in array of enum initializer (why create one though).
using static is unreadable, might cause conflicts and see dotnet/rosyln#20605 for possible unknown behaviour.
This might be subjective but take another look at this:
[AttributeUsageAttribute(Class | Struct | Enum | Delegate, Inherited = false)]
Why are there pipes in the attribute constructor again? What are Class, Struct.. and where from? What is 'Inherited' in this mess? In this example it is possible to figure out what Class and struct.. mean but consider user code and common flags like Public. IMO for syntactic sugar, it adds much more complexity than solve verbosity
@jnm2 It is not perfect and has some C++ to it but it is open for change and new opinions.

[HaloFour]

@Chi-TheCookie-Chi

is a possibly a breaking change

It would only be legal where it doesn't introduce an ambiguity, which would be relatively uncommon, but would not break any existing code. Where it would introduce an ambiguity it would be a compiler error and you could disambiguate by qualifying the enum.

This syntax has more applications than the one that you've proposed, such as being used in direct assignments, comparisons and switch statements/expressions. As above, where ambiguous you simply disambiguate by qualifying the enum. Java and Swift already manage enum lookup in this same fashion.

Why are there pipes in the attribute constructor again?

Because you are bitwise ORing together the values of those enums? They represent bitflags afterall, not discrete values, and it's possible (and not terribly uncommon) for an enum member to span multiple other enum members. The fact that you are performing a mathematical operation over integral values in order to produce an integral value is an important one that really shouldn't be glossed over.