Am 06.04.26 um 17:07 schrieb Emil Dotchevski via Boost:
On Mon, Apr 6, 2026 at 6:42 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Why are the enum_lookup_range limits necessary? As far as I could tell from my brief glance at the code, you simply cut the enum value names from function signature strings, no actual lookup is involved, so why the limits?
- enum_value_name() can be invoked with a variable at run-time. This is implemented in terms of indexing a constexpr array constructed over the lookup range at compile time. If the value is out of the lookup range, that's indicated in the state of the returned name object.
- 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. And lists of enumerator names will just be incomplete.
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 and/or have UB. At least you can specialize a trait for "your" enums, but it's in the boost::reflecto namespace so requires including that header first which is intrusive. Speaking of it: I'd suggest to allow specifying the first and last enumerators there, not (only) integers. Similar `static_cast<int>(EnumValue)` could be problematic.