Add enum reflection

[stephenberry]

[justend29]

As a note, many cases may want the enum serialized as integers. Supporting that is worthwhile.

[stephenberry]

I agree, the default behavior should still be integers.

I think reflection should happen if a glz::meta simply exists for the type:

enum class Color { Red, Green, Blue };

template <>
struct glz::meta<Color> {}; // This definition should trigger enum reflection

[justend29]

What are your thoughts on making it such that reflect = true must be in the struct to trigger reflection? It seems more explicit to me.

Then, as usual, the standard value = enumerate(...) would override.

[stephenberry]

Yeah, I think this is probably better for consistency, and then you can flip the reflect flag programmatically if you want:

template <>
struct glz::meta<Color> {
   static constexpr auto reflect = true;
};

[justend29]

Ouu, yes, flipping would be nice.
So, what would happen here?

template <>
struct glz::meta<Color> {
   static constexpr bool reflect = true;
   static constexpr auto value = enumerate(...);
};

I would think precedence would be as follows, meaning the above would autoreflect, regardless of value.

1. reflect == true -> auto reflect regardless of value (could instead produce an error if value is also present?)
2. no reflect and has enumerate value member -> use enumerate value
3. explicit reflect == true -> attempt to use value member, error on it missing

[stephenberry]

Agreed, I think glaze_reflect = true should override.

[stephenberry]

After thinking about this more, I think it is best to not add pure enum reflection until supported by C++26 (hopefully).

Tagged enum values make this more complex. And, it bifurcates enum handling logic.

It isn't hard to add a using enum statement and just copy the enum list into a glz::meta.

glz::meta also supports renaming enum values.

As cool as enum reflection would be, we don't want pure reflection as the default (integers are default). So, any additional reflection approach would be deprecated in the future. I'm less eager to add features that I know will have deprecated APIs.