-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Description
Now that we have PR #6324 merged, which allows us full static reflection of tables and structs, I propose we turn our attention to enums, which is the last remaining gap that lacks static reflection abilities. Currently, the generated code for enums does not allow for static reflection in a generic way. For example, if we have:
enum Color:byte { red, green, blue }
This will generate the following (in addition to the enum itself):
inline const Color (&EnumValuesColor())[3] { ... }
inline const char * const *EnumNamesColor() { ... }
inline const char *EnumNameColor(Color e) { ... }However, these are not usable in generic code because they can only be referenced through tokens containing the name of the enum. We had a similar problem with e.g. the CreateMonster class of functions. As a result, you can see in the C++17 unit test where we have to represent color as an integer instead of using the name of its value.
I propose that we add a static reflection feature for enums that would emit the following additional code in order to fix this:
namespace flatbuffers {
template<>
struct EnumTraits<MyGame::Example::Color> {
constexpr static auto values = MyGame::Example::EnumValuesColor;
constexpr static auto names = MyGame::Example::EnumNamesColor;
constexpr static auto name = MyGame::Example::EnumNameColor;
};
}and then it might also be necessary to add a few constexpr keywords to the EnumValuesColor, etc. Having this will fill the last remaining gap with generic/static reflection on flatbuffers types. In the Stringifier example that was recently added, this change will manifest by allowing the stringifier to obtain the real names of the enum values instead of just displaying their integer values as it does now (with the color field, for example).
@aardappel @vglavnyy what do you think?