[RFC] Rich enum constants without parens

[alexkaratarakis]

No description provided.

[younesr1]

I generally approve of this idea. I am leaving my thoughts as a comment rather than as PR review such that replies are simpler.

Specifically, I like that this change makes the common use cases of RichEnums simpler. For example, I like that we can omit operator() when comparing enums such as:

TestRichEnum1::value_of(BE::C_ONE) == TestRichEnum1::C_ONE

or in switch statements such as:

case TestRichEnum1::C_ONE:

However, the current approach has some downsides in my eyes.

1. The first downside in my opinion is that calling member functions of RichEnums now requires operator->, which in my opinion is an operator which conveys pointer like semantics which imply nullptr possibility. However, since the pointer will never be null in this case, this is a purely aesthetic concern and unfortunately I don't currently have alternate suggestions. Example:

TestRichEnum1::C_FOUR->ordinal()

2. I am not in favor of the

// TRANSITION
constexpr const RichEnumType& operator()()

In my opinion, this will result in having two different ways of doing the same thing and I expect both to stick around. From what I've seen, things in transition:: tend to stick around ;) . I suggest that we make this a breaking change that requires users to change their code. That is unless this repository has some convention of backwards compatibility.

[younesr1]

question from curiosity: I've noticed the pattern explicit(false) for a few ctors. What is the reason for it? Omitting it would have no effect since ctors are implicit by default, right?

[alexkaratarakis]

explicit(false) makes it explicit that the function is intended to allow implicit conversion and it is not an omission.