Re: (Boost) Reflecto

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 <
> [email protected]> 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

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/VTA6QHYAHKIHDCCAGYUVETZ27S6JQ5JP/