On 6 Apr 2026 18:07, Emil Dotchevski via Boost wrote:
On Mon, Apr 6, 2026 at 6:42 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 4 Apr 2026 21:47, Emil Dotchevski via Boost wrote:
I wrote a small constexpr type/enum reflection library which I think may be a good addition to Boost. It needs C++17, although it relies on implementation-specific support (works on gcc, clang and msvc).
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.
I think, if the above functionality may silently fail, if my enum happen to have values outside the limits, I would rather prefer if I had to explicitly specify the limits or the individual enum name<->value pairs. Having a functionality that "just works" is only good when it means "always works", not when it "usually works". Maybe the library could be split in two layers. The lowest layer would only deal with compile-time conversions that don't require limits or individual name<->value pairs. The runtime layer would be built on top of that and would require the user to "register" his enums for that layer to work. Although, I guess, Boost.Describe already provides that runtime behavior, so maybe that layer is not really needed.