(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. I really don't think we'll know what is
appropriate without experience of reflection proper.