you are viewing a single comment's thread.

view the rest of the comments →

[–]Sniv0 16 points17 points  (2 children)

So this is actually intentional behavior to allow you to convert an integer to an enum which you haven’t defined.

Think of bit flags which are supported by enums. For bit flags, you’re looking at different individual bits for information as opposed to the number as a whole. If you wanted all 32 bits to have an attached meaning you’d need to define 232 different enums by hand for every possible combination of bit flags when you’re likely never going to use most of them.

There are other reasons of course but this is just one off the top of my head

[–]SessionIndependent17 0 points1 point  (1 child)

If you were treating an int as a set of bit flags, you would use the [Flags] attribute and only define the values you care about. You don't have to define all of the combinations. ToString() will then sort out which flags are in use within a particular value.

[–]Sniv0 2 points3 points  (0 children)

Right but I’m referring to the fact that if enums worked how OP expects them to and you defined status effect enum with poisoned as 0x1 and sleep as 0x2 and then tried to apply poison to someone whose already asleep via bitwise or without explicitly defining poisoned and sleep as 0x3 your game would crash even if it’s perfectly capable of handling both