Hi Alexander, some feedback to your enum proposal:   Cardinality/automatic end ===================== When measuring the cardinality to add to the end or create an end marker as =cardinality+1, there are (at least) three cases:  - number of values defined so far  - number of values defined so far - 1 (if the first value is 0)  - maximum underlying value so far (if gaps are used)   Perhaps the end should not be defined as an enum value itself.   Bitmask enums ============= For bit-masking enums often constant flag-combinations are defined, including no flags, which equals 0 in the underlying type or all flags, which not necessarily (depending on whether the bits are all used) equals -1. In your notation those would be constants of the templated class-type. But perhaps it would make sense to mention those constants. Often those bitflag combination constants are currently put into the same enum as the flags and can contain 0. Your templated class would give those another type.   The templated class in its current form does not support bitfields, where one flag needs more than one bit.   Sebastian     -----Ursprüngliche Nachricht----- Von:Alexander Christensen via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 30.07.2023 18:28 Betreff:[std-proposals] Revision 1 of scoped enum enhancements An:std-proposals_at_[hidden]; CC:Alexander Christensen <alex_c007_at_[hidden]>; Hi all,   After a (longer than expected) period of thinking my initial proposal through, I here send a "revision 1". I posted some time during winter 2021/22 a draft for how we can enhance scoped enums, and notably here - extended with bitmasking, as well as a lot of cleanup and testing.   It is a compiled pdf document of 15 pages, so I present a link: https://github.com/alexpanter/cpp-enum-proposal/blob/master/revision-1/report.pdf   I'm really looking forward to your feedback.   Best, Alexander   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals