Am 10.04.26 um 23:32 schrieb Emil Dotchevski via Boost:
On Tue, Apr 7, 2026 at 3:12 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
Am 06.04.26 um 17:07 schrieb Emil Dotchevski via Boost:
- enum_value_names<E> returns a constexpr array of name/value pairs (like Describe does for described enums) that includes only the named values; there is also named_enum_value_count and min_/max_named_enum_value. That sounds like a heavy footgun: You can always get the name of an enumerator / all enumerators , except when you cannot. For name<->enumerator conversions you could throw/static_assert to detect this case. For try-to-name like functions you cannot.
For runtime lookups, the returned name object can be checked to see if the lookup was successful. That's the best behavior possible (it is not undefined behavior). My point was: At runtime you cannot check if you really got all enumerators unless you know them or their range already. And hence you cannot convert a string to enumerator distinguishing an invalid name from one missed by the library.
This is amplified by this being a define (BOOST_REFLECTO_DEFAULT_ENUM_MIN_VALUE): When someone (e.g. a consumer of your library built on reflecto) has already included reflecto and/or defined those then your code will suddenly break
This is a very good point and it inspired me to find a solution. Now the enum_lookup_range can be specified for all enums within a given namespace, not just for individual enums:
namespace lib1 { struct this_namespace;
enum class some_enum { .... }; }
namespace boost::reflecto { template <> struct enum_lookup_range<specialize_for_namespace<lib1::this_namespace>> { // specialization applies for any enum within the namespace lib1, // including lib1::some_enum. }; }
I made this machinery part of the public API in meta_specialization.hpp, so the ability to look up a template specialization based on the namespace of some type is universally available, see https://github.com/zajo/reflecto?tab=readme-ov-file#meta-specialization. _______________________________________________
That's better, yes. Just for comparison: For a case where I needed the range of enumerators reliably I added customization points as opt-in: `constexpr Enum getLastEnumerator(Enum)` This was supposed to be implemented for an enum to opt-in with the contract that enum values from 0 to the returned one are valid. It can be put right after the enum definition where it is easy to verify and update, and doesn't require any includes. Your trait needs including a reflecto header and likely remembering to include the header where the trait is defined before using the reflecto machinery. Not sure how well this works on all compilers depending on the include order. I remember having had issues with Boost.Test to specialize the `boost_test_print`(?) trait to get my own types to be streamable. But there it was at least a compile error. To be clear: I'm NOT saying there is a better solution than yours, just want to make sure you and ultimately the users of reflecto are aware of such subtleties