GEODE-10096: Replaced macro definitions with enumerations.

[mreddington]

No description provided.

[jake-at-work]

I am torn on this... I both like and dislike it.

Dislikes:

• The name, underlying doesn't feel right, but I can't put my finger on it. to_ordinal?
• It sort of undoes one of the key features of enum class by casting the enum something, you don't really see what, that can decay to another type.
• Doesn't have a reverse like static_cast does so there is no mirror operation going back and forth between enum and ordinal value.

Like:

• Hides the mess of casting to a int type.

🤷

[mreddington]

Counterpoints:

• This is a direct copy of an STL utility we just don't have in C++11.
• Look where I'm using it - at some point, we need to write these enum values to the byte stream. Now there are two ways we can do that:
  • We can map an enum to a value, and a value to an enum, like via some switch statement. If we do that, then we don't need to specify the enum values themselves, since we'd never cast the enum to or from an integer type. This is just redundant in every way.
  • We cast the enum where we write bytes to the wire.
• It doesn't need a reverse. You can static cast any integer to an enum and the compiler will let you know if you're narrowing, but if you want to cast from an enum to the numeric type used to implement it, that's built into the enum type but you wouldn't know it, or can't rely on it since it can change, either by the compiler, or in the case of an enum class, the implementer. The compiler always knows, so this leverages deduction to get it right for you.

But I feel you. I don't like the use of enums overall. There's just something about them that don't seem "good enough". I don't think C++ would have had enumerations in the form we have them today if we didn't inherit from C, so I'm always aware of the loose type safety they come with.

[jake-at-work]

Oh, I wasn't aware they added this in 14. Well then... if the C++ gods like it then we should too. Thanks!