More robust enum reflection

[stephenberry]

No description provided.

[ZXShady]

Hi stephenberry, I noticed this uses my implementation thank you for considering it. is there a reason for dropping this idea?

I improved the older compiler support in the latest commit (the commit is stable)

[stephenberry]

@ZXShady, I really like your implementation, but felt it could use some improvements and tighter integration with the rest of Glaze, so this was an experiment. I just haven't had the time to focus on better enum reflection in Glaze, but I'll hopefully get to this soon.

I'll definitely take a look at your recent improvements for enchantum. And, I'll try to give some feedback based on the changes I end up making. I just remember some of your code being more complicated than it needs to be.

Thanks for all your work on enum reflection in C++!

[ZXShady]

@ZXShady, I really like your implementation, but felt it could use some improvements and tighter integration with the rest of Glaze, so this was an experiment. I just haven't had the time to focus on better enum reflection in Glaze, but I'll hopefully get to this soon.

Thanks for all your work on enum reflection in C++!

I don't think it should be integrated directly into glaze it is a reflection library for general use.

Wouldn't this work? doesn't seem to need to directly integrate

template <enchantum::Enum E>
struct glz::meta<E> {
    static constexpr auto values = enchantum::values<E>;
    static constexpr auto keys = enchantum::names<E>;
};

I'll definitely take a look at your recent improvements for enchantum. And, I'll try to give some feedback based on the changes I end up making. I just remember some of your code being more complicated than it needs to be.

my code is indeed complicated, but this is because of compiler quirks, a very simple one was how a simple constexpr auto& caused msvc binary sizes to explode removing the & fixed the issue it was fun, so the code is ugly for both compile time speed and binary sizes (which I improved alot in latest commits by using generators)

[stephenberry]

You're totally right that someone can use your library in Glaze right now with something like:

template <enchantum::Enum E>
struct glz::meta<E> {
    static constexpr auto values = enchantum::values<E>;
    static constexpr auto keys = enchantum::names<E>;
};

But, in order to support more compile time options, integrating enums with variants, etc. Glaze needs to have deeper integration. We also want to be able to do things like rename just one enum value, apply transformations to the names, etc. that Glaze can better support with direct integration.

[ZXShady]

You're totally right that someone can use your library in Glaze right now with something like:

template <enchantum::Enum E>
struct glz::meta<E> {
    static constexpr auto values = enchantum::values<E>;
    static constexpr auto keys = enchantum::names<E>;
};

But, in order to support more compile time options, integrating enums with variants, etc. Glaze needs to have deeper integration. We also want to be able to do things like rename just one enum value, apply transformations to the names, etc. that Glaze can better support with direct integration.

for renaming 1 enum value that can be apllied directly on enchantum

template<class E>
constexpr std:: array<std::pair<E,std::string_view>,0> rename = {};

template<>
constexpr std::pair<UrEnum,std::string_view> rename<UrEnum>[]
= {
      {UrEnum::Value,"Renamed"}
};

template<class T>
constexpr auto glaze_enum_names = []()
{
    std::array<std::string_view,enchantum::count<T>> a{};
    std::size_t i = 0;
    for(auto [value,string] : enchantum::entries<T>)
    {
         a[i] = string;
         for(auto [v,s] : rename<T>)
         {
                if(value == v) {
                    a[i] = s;
                    break;
                 }
         }
         ++i;
    }
    return a;
}();
template<class E>
std::string_view enum_to_string(E e)
{
    for(std::size_t i = 0;i < enchantum::count<E>;++i)
     {
         if(e == enchantum::values_generator<E>[i])
                return glaze_enum_names<E>[i];
     }
}

I don't think what you mentioned actually needs direct integration, it could be algorithms on top of enchantum, I for example have snake_case to camelCase functions in my code that applies on enchantum

[ZXShady]

Do I work on a pr for glaze or no to prevent duplicated prs?

[stephenberry]

@ZXShady, I'm probably going to delete this PR. What would be the aim of your PR?

[ZXShady]

@ZXShady, I'm probably going to delete this PR. What would be the aim of your PR?

1. Use enchantum as the backend for enum reflection not directly copy the source of it inside glazs.

2. Since by default all enums are serialized by ints and reflecting them by default would be a breaking change maybe there should be a bool that the user enables template<> constexpr inline bool glz::serialize_enum_with_names<MyEnum> = true; which auto reflects it.

3. Make it work for tagged variants.

[stephenberry]

Thanks so much for your offer, but enum reflection is simple enough that we don't want to bring on a third party dependency. We need to be able to control core functionality for our clients and be able to make fixes within sometimes minutes.

I would be open to bringing a single include header of enchantum as a dependency, except that there are a variety of changes that I'd like to make and I don't want to drive your development.

[ZXShady]

Thanks so much for your offer, but enum reflection is simple enough that we don't want to bring on a third party dependency. We need to be able to control core functionality for our clients and be able to make fixes within sometimes minutes.

I would be willing to fix issues within minutes as well.

I would be open to bringing a single include header of enchantum as a dependency,

I am personally against single headers for compile time reasons, I only have one for godbolt testing.

except that there are a variety of changes that I'd like to make and I don't want to drive your development.

I wonder what changes that cannot be directly built on top of enchantum I showed for example having custom names for enums by just using enchantum.

the feecback could be interesting for me to extend my library to allow more customization.

[stephenberry]

Okay, after giving more thought and seeing your enthusiasm I'm open to utilizing enchantum more directly. If you want to make a pull request I'll over it in detail and let you know my thoughts.

[stephenberry]

@ZXShady, after looking at this a bit more I think I've been able to update this pull request to a decent place. So, I don't think we'll rely on enchantum, although I think your work is great. A large motivation is that Glaze will be transitioning to embrace C++26 reflection, which will remove the need for much of this code and require a smooth transition. By having closer integration with the rest of Glaze it makes that transition easier.

[ZXShady]

@ZXShady, after looking at this a bit more I think I've been able to update this pull request to a decent place. So, I don't think we'll rely on enchantum, although I think your work is great. A large motivation is that Glaze will be transitioning to embrace C++26 reflection, which will remove the need for much of this code and require a smooth transition. By having closer integration with the rest of Glaze it makes that transition easier.

It would. enchantum is for those who don't want to wait like me :P but it would also require the absolute latest compilers.

I actually just forked glaze to work on it lol

i also made a similar pr before getml/reflect-cpp#441

[ZXShady]

There is also a benefit to using enchantum directly which is that if 2 users are using enchantum and glaze their compile times won't get doubled.

I made this quick branch [enchantum]

https://github.com/ZXShady/glaze

Also I doubt msvc will even implement reflection in the next 2 years so upping the requirement for C++26 seems a stretch