Consider options for allowing a [Flags] enum to be automatically populated.

[The-Futurist]

The [Flags] attribute used for enums is very helpful but sadly requires the developer to manually specify the value of each member using one of several options, all of which are laborious:

https://stackoverflow.com/questions/10558621/any-trick-to-defining-an-enum-as-flags-powers-of-2-without-eventually-needing-a/47729978#47729978

So why not provide a way to do this automatically (and reliably, reducing risk of typos that could go undetected even in heavy testing)?

Here's one option that springs to mind, add a new constructor overload for [Flags] -> [Flags(AutoPopulate: true)].

This would never break existing code because the attribute overload would be new, but this (I guess) is not actually a C# language change but a framework change, but I assume it would entail some compiler support..

[svick]

[Flags(AutoPopulate: true)] would mean the same code would have different results on different versions of the compiler: if you target new framework with old compiler, it wouldn't auto-populate. If you then switched to the new compiler, it would suddenly auto-populate.

Not sure if this is a big issue.

[iam3yal]

Well, all these proposals can go into the source generation category, there's no ETA but hypothetically it's a good fit.

[orthoxerox]

I don't feel that the benefit outweighs the cost here. Just how often do you write flag enums? I think an extension that gives you a lightbulb option to autofill your enum declaration would be a better option.

[jnm2]

@orthoxerox Interop. Though with interop, autofilling with 1 << 0 ... 1 << n would rarely be helpful anyway. But I do like where you're going with that.

[The-Futurist]

@orthoxerox, @svick, @eyalsk - Well enums are already auto populated but using an incrementing integer for each member in their declared order and I don't create many enums very often so I don't think frequency of creating them is a factor. What led me to post this is that I made an error in a new Flags enum that has 30 members, and the error was subtle but led to one member having more than one bit set on.

This ended up taking a couple of hours before I discovered the cause of very odd behavior, so I'd argue the time saved in potential problem diagnosis is the true benefit here.

Imagine we had to manually specify ordinary enum values then consider the kinds of pain we end up with over time with out of order values, duplicates etc.

Another alternative is to introduce a new type "flags" which becomes a new keyword and mirrors the current [Flags] enum behavior.

Then it could only be used in new versions and the compiler could do all the work.

Another alternative which would be enough I think, is a compiler warning that there are members in a [Flags] enum that do not follow the expected bit pattern that's the hallmark of such an enum.

[HaloFour]

An analyzer would probably be pretty helpful here. Have it warn if you're writing such an enum where you aren't explicitly specifying integral values and where any of the integral values overlap. If you want intentional overlap you have to | together other values:

[Flags]
public enum MyFlags
{
    A, // warning, no explicit value
    B = 1,
    C = 2,
    D = 3, // warning, overlaps values for B and C
    E = B | C, // good
}

I think that with binary literals it is a little easier to write flag enums since you can see the bitflags a lot easier.

[The-Futurist]

@HaloFour - I guess I need to read about these analyzers, are these akin to VS extensions? things one installs into VS either by writing one's own or installing from a 3rd party?

[Joe4evr]

You can install them as a NuGet package.