Add static reflection for enums to construct matching MooseEnums

[dschwen]

Reason

We often use a pattern where a MooseEnum parameter is fetched and immediately converted into an enum class object. If the labels for the two enum types do not match very confusing bugs can be introduced.

Design

We could use static reflection to construct a MooseEnum from an existing enum class, setting all the valid items to the string representations of the enum class items. The construction of such a MooseEnum could look like this

enum class Options {
   FIRST_OPTION, SECOND_OPTION, NONE
};

auto optionEnum = MooseEnum::fromEnum<Options>();

which would give the same result as

MooseEnum optionEnum("FIRST_OPTION SECOND_OPTION NONE");

(I'm sure there is support for specific underlying type values (FIRST_OPTION=1, SECOND_OPTION=2, NONE=0) and, an option to specify the default value auto optionEnum = MooseEnum::fromEnum<Options>(Option::NONE); could be added as well).

The library to do this is https://github.com/Neargye/magic_enum, however, it would require us to raise the minimum compiler requirements, and it would rely on non-standard, albeit well supported, compiler features.

I'm opening this issue, because the question of enum consistency has come up multiple times now (I believe by @tophmatthews and @hugary1995), and I want some permanent record for when we arrive at sufficiently recent minimum supported compiler versions.

Impact

New API to enforce consistency between corresponding enum type eliminates a source for bugs.

[roystgnr]

That library requires not only C++17, but also

a compiler-specific hack (based on __PRETTY_FUNCTION__ / __FUNCSIG__)

Are you sure you didn't get the title correct the first time?

:drum: :bell:

[roystgnr]

More seriously, though - we could use this immediately for verifying enum strings, even if we can't rely on it for generating them.

If we can get constexpr outputs from this, then we can stick those in a comparison in a static_assert so that the hand-written strings get verified with every CI build on a hack-supporting compiler, and we can wrap all that in some #ifdef ENUM_REFLECTION_HACK as well as #if __cplusplus > 201703L so it doesn't break on random non-C++17 or non-hack-supporting compilers.

[roystgnr]

Less seriously again - is there really no better emoticon to use for the crash following a rimshot? Lacking a simple cymbal symbol is some bull.

[dschwen]

The enum_name function is indeed constexpr, but we'd also need a compile time way to split strings along spaces and iterator over them. This can probably be done with parameter packs and tons of template magic. But I'll hold off on this until we support C++17.

Maybe we should add a label for issues that are waiting on C++17...

[loganharbour]

Maybe we should add a label for issues that are waiting on C++17...

I like this. Will help us keep track when we finally get it going

[loganharbour]

I'd like to note that we do actually have c++17 with the default compiler on the build boxes, so there isn't anything stopping you from testing the majority of the stuff on next right now

[roystgnr]

Yeah, not only that but our min clang tests are getting run on C++17, so you should be able to differentiate the different types of failure: Min gcc failure is expected and means you're actually using C++17, Min clang failure means you accidentally used some C++20 or something, other failures mean actual failures.