There are enum reflection libraries out there, AFAIK they are implemented by abusing __PRETTY__FUNCTION__. I used magic_enum before:

https://github.com/Neargye/magic_enum

Point being, there is existing practice. A proposal should evaluate the existing practice for the API design.


On 25 September 2022 16:54:55 BST, Edward Catmur via Std-Proposals <std-proposals_at_[hidden]> wrote:
>(re-adding list; hope this is OK)
>
>On Sun, 25 Sept 2022 at 16:34, Jason McKesson <jmckesson_at_[hidden]> wrote:
>
>> > I'm not sure we could agree on what we want. Enums can be empty, or
>> forward declared (with an underlying type); the range of enumerators may be
>> those named, or it may be those named less sentinel values, or it may be
>> some arithmetic closure of the named enumerators (e.g. for enumerations
>> with bitwise operations).
>> >
>> > The only way to handle all of these is with reflection (over the named
>> enumerators, and possibly metadata).
>>
>> Your argument is structurally equivalent to the argument that, because
>> some people want to have a vector-like type that has a hard cap on its
>> allocation size or always uses a built-in buffer, we shouldn't have
>> `std::vector` since it cannot cover all of those cases. No, `vector`
>> is legitimately useful to actual users even though it's not useful for
>> everyone.
>>
>> The same goes here; basic high-level tools don't have to handle every
>> single case. Remove all the cases where a user wants to only consider
>> *some* enumerators (ie: sentinels), and we can come to an agreement
>> pretty quickly on what those tools ought to be.
>>
>> Fear of not being able to help everyone should not stop us from helping
>> someone.
>>
>
>I don't think the analogy holds. OP was already requesting density
>statistics, so it's questionable whether min() and max() even constitute a
>MVP.
>
>But also, `<vector>` standardized existing practice, and didn't prevent
>people writing their own contiguous containers with specialized semantics.
>(Uh, other than the array problem, which isn't an issue in practice, since
>compiler vendors know to DTRT.) Given reflection, library authors
>(Boost.TypeTraits, e.g.) can settle on an appropriate collection of
>statistics and then the Standard can provide them once practice is
>established.
>
>Our experience (using Boost.Describe for reflection) is that some of the
>time min() and max(), plus bool dense(), are sufficient. But often we also
>want to list the enumerators, sort them, uniquify, name, validate, lift
>from runtime to compile time, etc.

As I recall magic_enum does all of these.

> I really don't think we'll know what is
>appropriate without experience of reflection proper.

Cheers,
Lénárd