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@gmail.com> 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@gmail.com> 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@lists.isocpp.org> w dniu 14 mar 2025, o godz. 12:43:

 AW: [std-proposals] lambdas in enums

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@gmail.com>
Gesendet: Fr 14.03.2025 12:33
Betreff: Re: [std-proposals] lambdas in enums
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>; std-proposals@lists.isocpp.org;
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals