Supporting enums with non-integral underlying values is a very different
concern than member functions or whatnot but I do think it would be a
useful feature.

+1 to just making it enum class E : std::pair<…> or whatnot instead of some
weird type list.

Cheers,
Jeremy

On Fri, Mar 14, 2025 at 07:33 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>