On Sun, 25 Sept 2022 at 16:06, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Sep 25, 2022 at 11:03 AM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> 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).