Please add support for bitwise shift operators on enums

[weitzhandler]

Description

In [Flags] annotated enums, I often want to move an enum property to the next value, something like the ++ operator, but for enum.

[Flags]
public enum DaysInWeek { Sunday = 1, Monday = 2, Tuesday = 4, Wednesday = 8 ..... }
public class Store
{
  DaysInWeek OpenDays { get; set; }
}

What I want, is to be able to move the property value to next day:

Example usage

//initial value
store.OpenDays = DaysInWeek.Sunday;

//move next (check if smaller than sat)
store.OpenDays <<= 1; //will become Monday

Current behavior

Currently it's achievable like this:

store.OpenDays = (DaysInWeek)((int)store.OpenDays << 1);

My suggestion is to add << and >> bitwise shift operators to Enum, so that we can benefit from this without casting.

Notes

Maybe the DaysInWeek example I gave here isn't the right one to demonstrate the motive so well. Just imagine you have an enum that is in some cases supposed to be a single value and you want to advance it to next value. And BTW, a multi-value enum will move to the next set of values (i.e. if it's set to Sunday,Monday, shifting by one will set it to Monday,Tuesday.
Additionally, take into account that enum supports all int operations, including ++ or -- , I think it should be just natural to also enable the bitwise shift operators to complete the picture.

Initially posted here: https://github.com/dotnet/corefx/issues/23524.

[jnm2]

I think the casting is a good thing because it alerts people to the fact that you're doing something which is generally unintuitive and difficult to reason about.

[weitzhandler]

@jnm2 ++ doesn't need any casting. store.OpenDays++ is valid, so make <<= valid too.

[jnm2]

@weitzhandler I'm not downvoting, but that still doesn't change my mind though. I'll let others weigh in.

[iam3yal]

@weitzhandler I wouldn't say the proposal doesn't make sense but I think that at least in this case, it makes more sense to provide a thin wrapper over the enum and add methods that make sense for it such as NextDay, LastDay than relying on language operators to manage it, what if tomorrow you decide to change the type or its values to something else? but then again it might make sense to add it for completeness.

[jnm2]

but I think that at least in this case, it makes more sense to provide a thin wrapper over the enum and add methods that make sense for it

I use extension methods but I'm also excited about #297.

[iam3yal]

@jnm2 Totally. ;)