C# Enums – Is It Wrong to Use Flags for Grouping Enums?

The simplest way is to provide the operator overloads yourself. I am thinking of creating a macro to expand the basic overloads per type.

#include <type_traits>

enum class SBJFrameDrag
{
    None = 0x00,
    Top = 0x01,
    Left = 0x02,
    Bottom = 0x04,
    Right = 0x08,
};

inline SBJFrameDrag operator | (SBJFrameDrag lhs, SBJFrameDrag rhs)
{
    using T = std::underlying_type_t <SBJFrameDrag>;
    return static_cast<SBJFrameDrag>(static_cast<T>(lhs) | static_cast<T>(rhs));
}
    
inline SBJFrameDrag& operator |= (SBJFrameDrag& lhs, SBJFrameDrag rhs)
{
    lhs = lhs | rhs;
    return lhs;
}

(Note that type_traits is a C++11 header and std::underlying_type_t is a C++14 feature.)

HaXe enums are algebraic data types (ADTs). Your example in Haskell:

data Color3
  = Red
  | Green
  | Blue
  | Grey { v :: Int }
  | Rgb { r, g, b :: Int }
  | Alpha { a :: Int, col :: Color3 }

In either language, this type simply expresses that a Color3 has a few possible values—red, green, or blue; a grey value; an arbitrary RGB value; or a Color3 value with an additional alpha channel. The fact that some of these constructors take extra parameters should not be alarming. It is simply a terse closed analog to the open behaviour of inheritance:

class Color3 {}

class Red : Color3 {}
class Green : Color3 {}
class Blue : Color3 {}

class Grey : Color3 {
  public var v:int;
  public function Grey(v:int) {
    this.v = v;
  }
}

class Rgb : Color3 {
  public var r:int, g:int, b:int;
  public function Rgb(r:int, g:int, b:int) {
    this.r = r;
    this.g = g;
    this.b = b;
  }
}

class Alpha : Color3 {
  public var a:int;
  public var col:Color3;
  public function Alpha(a:int, col:Color3) {
    this.a = a;
    this.col = col;
  }
}

Here anyone can come along and add a new Color3 child class that may or may not respect the properties we want to enforce. With parameterised enums we have central control over all the constructors, and we also have pattern matching:

return switch (c) {
  case Red: 0xFF0000;
  case Green: 0x00FF00;
  case Blue: 0x0000FF;
  case Grey(v): (v << 16) | (v << 8) | v;
  case Rgb(r,g,b): (r << 16) | (g << 8) | b;
  case Alpha(a,c): (a << 24) | (toInt(c) & 0xFFFFFF);
}

Contrast the alternative of adding a toInt() method to every subclass of Color3. It would be much more code, leading to more potential for errors.

Note that this particular example isn’t great because a few of the constructors are redundant: Rgb subsumes Red, Green, Blue, and Grey, and Alpha can be applied to a colour that already has Alpha, which may not be desirable.