> 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
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.