-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Rich enum constants without parens #136
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ | |
#include <magic_enum.hpp> | ||
|
||
#include <array> | ||
#include <compare> | ||
#include <concepts> | ||
#include <cstddef> | ||
#include <functional> | ||
|
@@ -364,14 +365,59 @@ class SkeletalRichEnumStorageBase<RichEnumType, | |
|
||
} // namespace fixed_containers::rich_enums_detail | ||
|
||
template <typename RichEnumType> | ||
class RichEnumConstantProxy | ||
{ | ||
private: | ||
using BackingEnum = typename RichEnumType::BackingEnum; | ||
|
||
BackingEnum backing_enum_{}; | ||
|
||
public: | ||
explicit(false) constexpr RichEnumConstantProxy(const BackingEnum& backing_enum) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question from curiosity: I've noticed the pattern There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
: backing_enum_{backing_enum} | ||
{ | ||
} | ||
|
||
constexpr RichEnumConstantProxy(const RichEnumConstantProxy& original) noexcept = delete; | ||
constexpr RichEnumConstantProxy(RichEnumConstantProxy&& RichEnumConstantProxy) noexcept = | ||
delete; | ||
constexpr RichEnumConstantProxy& operator=(const RichEnumConstantProxy& RichEnumConstantProxy) = | ||
delete; | ||
constexpr RichEnumConstantProxy& operator=(RichEnumConstantProxy&& original) = delete; | ||
|
||
constexpr const RichEnumType& get() const | ||
{ | ||
return ::fixed_containers::rich_enums_detail::value_of<RichEnumType>(backing_enum_) | ||
.value() | ||
.get(); | ||
} | ||
|
||
explicit(false) constexpr operator BackingEnum() const { return get(); } | ||
explicit(false) constexpr operator const RichEnumType&() const { return get(); } | ||
|
||
// TRANSITION | ||
constexpr const RichEnumType& operator()() const { return get(); } | ||
|
||
constexpr bool operator==(const RichEnumType& other) const { return get() == other; } | ||
constexpr std::strong_ordering operator<=>(const RichEnumType& other) const | ||
{ | ||
return get() <=> other; | ||
} | ||
|
||
constexpr const RichEnumType* operator->() const { return std::addressof(get()); } | ||
constexpr const RichEnumType& operator*() const noexcept { return get(); } | ||
constexpr const RichEnumType* operator&() const noexcept // NOLINT(google-runtime-operator) | ||
{ | ||
return std::addressof(get()); | ||
} | ||
}; | ||
|
||
// MACRO to reduce four lines into one and avoid bugs from potential discrepancy between the | ||
// BackingEnum::ENUM_CONSTANT and the rich enum ENUM_CONSTANT() | ||
// Must be used after the values() static function is declared in the rich enum. | ||
#define FIXED_CONTAINERS_RICH_ENUM_CONSTANT_GEN_HELPER(RichEnumName, CONSTANT_NAME) \ | ||
static constexpr const RichEnumName& CONSTANT_NAME() \ | ||
{ \ | ||
return RichEnumName::value_of(BackingEnum::CONSTANT_NAME).value(); \ | ||
} | ||
static constexpr RichEnumConstantProxy<RichEnumName> CONSTANT_NAME{BackingEnum::CONSTANT_NAME}; | ||
|
||
namespace fixed_containers::rich_enums | ||
{ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 omitoperator()
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.
RichEnums
now requiresoperator->
, 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()
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.