On Sun, Sep 25, 2022 at 11:03 AM Thiago Macieira via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
> On Sunday, 25 September 2022 07:55:18 PDT Jason McKesson via Std-Proposals
> wrote:
> > That should not be to say that we shouldn't have higher-level
> > metafunctions to compute these kinds of aspects of an enumeration than
> > saying "build it yourself with reflection whenever we bother to give
> > that." But they should not be called "numeric_limits".
>
> I've always expected we get a set of traits classes and functions that are
> built on the lower-level reflection to provide a nicer API, for things like
> this, as part of the reflection additions to the standard. Sorry, this was
> implied in my answer, but should have been explicit.
My point is that such tools should be considered orthogonal to
reflection. We could get a set of basic enum tools in the standard for
C++26, even though reflection seems like it is going to land in the
2030s or so. We need these tools regardless, and whether they are
user-implementable or not is kind of irrelevant.
C++11 didn't wait for us to be able to implement type-traits before
giving them to us. Enum tools should be the same way.
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).