Add Enum.SetFlag and Enum.RemoveFlag to make bitwise flagging easier

[yufeih]

To maintain multiple bool states in a class, instead of declaring many bool fields, an enum flag can be used to compact these states in to a single member to optimize for memory usage.

[Flags] enum DirtyFlags { X = 1, Y = 1 << 1, Z = 1 << 2 };

DirtyFlags dirtyFlags = DirtyFlags.X | DirtyFlags.Y | DirtyFlags.Z;

It is simple to test if a flag is set using Enum.HasFlag(DirtyFlags.X), but the scenario is not complete. Without the ability to set and remove a flag, the following code needs to be maintained manually:

// Setting a flag
dirtyFlags |= DirtyFlags.X;
// Removing a flag, this is harder to remember :(
dirtyFlags &= ^DirtyFlags.X;

The suggestion is to add 2 methods to Enum to help set and clear a flag.

public bool HasFlag(Enum flag); // This method already exists
public bool SetFlag(Enum flag);
public bool RemoveFlag(Enum flag);

These methods should be aggressively inlined since bitwise manipulations is very likely to be used in a performance sensitive scenario.

[mikedn]

With the current language and runtime capabilities there's no way to implement SetFlag and RemoveFlag efficiently. Even the existing HasFlag has horrible performance compared to the "manual" way of testing flags.

[Alexx999]

@yufeih enum is now implemented in, well, not nice way. It's half-struct half-class which can turn out be any type in practice, and framework uses tons of hacks and quirks to make it work like it should.
So @mikedn is probably right - it will be hard to make it work fast.
However, it's probably worth trying.

UPD: Okay, looked at it for a bit more... I believe not much can be done here without changing specifications for enum. Now, argument for HasFlags is treated as object, so it requires boxing-unboxing and has corresponding performance hit.
It will not work fast without some serious changes in how enums work (generics?) but that will probably require changes at runtime and/or compilers.

[HellBrick]

This is another example where enum constraint on a generic argument (dotnet/roslyn#262) would be useful. It would allow something like

T WithFlags<T>( this T source, T flagsToAdd ) where T: enum { /* ... */ }
T WithoutFlags<T>( this T source, T flagsToRemove ) where T: enum { /* ... */ }

[HaloFour]

@HellBrick Even with the enum constraint the problem is that the underlying type could be anything from sbyte to ulong and the IL for the bitwise math would have to be different for each of those types.

Some of this came up on the CodePlex Roslyn forums when I proposed supporting an enum constraint for C# generics with support for | and &.

[mikedn]

sbyte to ulong and the IL for the bitwise math would have to be different for each of those types

As I explained before, the bitwise operations themselves are fine. The problem is with conversions that are needed in certain cases. That's something that could probably be fixed in the runtime, at least in the specific case of enums.

[terrajobst]

@mikedn

With the current language and runtime capabilities there's no way to implement SetFlag and RemoveFlag efficiently. Even the existing HasFlag has horrible performance compared to the "manual" way of testing flags.

I agree with this with why I believe we shouldn't add these APIs.

@weshaggard @KrzysztofCwalina what are your thoughts?

[yufeih]

I can see how HasFlags is implemented in a really inefficient way. These methods should not be added like that. Maybe some kind of JitIntrinsic from coreclr might help here?
If the effort is not worth the outcome, I am fine with leaving things as is.

[KrzysztofCwalina]

@terrajobst, I agree that we don't want to simply add these APIs, but I would put this (efficient flags/bitwise operations) issue on our list of big ticket items that we would like to consider fixing as part of the "modern BCL" push.

[HaloFour]

It would make a lot more sense to wait until C# supported generic enum constraints:

dotnet/roslyn#262

[KrzysztofCwalina]

I am not sure how enum constraint would help. The type system still needs to describe the size of the backing integral type to implement many of these operations efficiently. I think something like making enums extend Enum where T: integral type would be needed.

[HaloFour]

@KrzysztofCwalina True. Not perfect, but wouldn't an unchecked cast to ulong and then back to the enum type be more efficient than what we have today?

[terrajobst]

Not sure that would work in all cases either. What if the enum is backed by a double/float? C# doesn't support CLI does.

[kornman00]

@terrajobst is there online documentation covering that fact (CLI supporting non-integral backing types for enums)? Not finding any obvious results with my Google-fu

[mikedn]

is there online documentation covering that fact (CLI supporting non-integral backing types for enums)? Not finding any obvious results with my Google-fu

Hmm, didn't notice this comment before. There's no such enum, CLI supports only enums of integral type:

The symbols of an enum are represented by an underlying integer type: one of { bool, char, int8, unsigned int8, int16, unsigned int16, int32, unsigned int32, int64, unsigned int64, native int, unsigned native int }

The difference between what CLI supports and what C# supports is { bool, char, native int, native unsigned int }