It is you who wants to extend the types or "different values that can be stored" in the first place: Going from a single underlying type to several, using non-integral types. But I respect that you do not want to allow it without limits.   If you want to limit the usable types to around 5: Which are they? Perhaps a group of types should be prefered with certain properties (like integral or something else).     Listing the types separately       enum class E : int, float   does not group them much more than      enum class E : struct { int i; float f; }   or       enum class E : std::tuple<int, float>     Would it be possible to access the underlying types? Or convert to and from? Or can those extended enums only be accessed with E::A or similar as fixed values?     You want to use const char*? Is it interpreted (=compared) bytewise (or char-wise) and are NUL values allowed in the middle?   Such long types are more difficult to handle: set, compare, copy, pass as parameter, use as key in a data structure, ... enum types are meant to be simple       -----Ursprüngliche Nachricht----- Von:Filip <fph2137_at_[hidden]> Gesendet:Fr 14.03.2025 13:19 Betreff:Re: [std-proposals] lambdas in enums An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden]; We could use struct and tuples, but enum struct would lower the amount of different values that can be stored, being precise should limit the possible errors in my opinion. Instead of struct of int float and const char* with almost infinite amount of possible values, you could just have 5 for the user to choose from.  It would also group together related terms and make them easy to use and less error prone when setting the system up.  Error code next to its message.  With limited amount of possible values we are safer in this regard and we have the added benefit of compiler assistance in using only specified values. Cheers, Filip Wiadomość napisana przez Filip <fph2137_at_[hidden]> w dniu 14 mar 2025, o godz. 13:07: Now that I think about enum I want question the fact that we cannot iterate over them in a for loop:  for (auto e : someEnum) This should be a simple unroll even but still, compiler has all the information to make this happen: number of elements and types of everything. Cheers, Filip Wiadomość napisana przez Filip <fph2137_at_[hidden]> w dniu 14 mar 2025, o godz. 12:48: Yes it could, but maybe we shouldn’t limit ourselves with types of enum to just integral types. Maybe the only things that should be considered is ++ and construction at compile time.  In this example we could just use std::pair but what if you want 4 types? Cheers, Filip Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 14 mar 2025, o godz. 12:43:  The enum in this case could have a std::pair<int, float> as fundamental type instead. Wouldn't that be simpler and more flexible, as this class (in this case std::pair) could provide added functionality, e.g. suitable constructors.   -----Ursprüngliche Nachricht----- Von:Filip <fph2137_at_[hidden]> Gesendet:Fr 14.03.2025 12:33 Betreff:Re: [std-proposals] lambdas in enums An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden]; sizeof an enum is essentially a sizeof its underlying type, so it should be the sum of sizeof of each type.  C and D are valid. if the compiler can ( and should ) compare them and optimize the storage, then it could be optimized. However then you would ensure that operator== is implemented for it to be used. Cheers, Filip -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals