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.