I will finish the rest of the code tomorrow but please please criticize it.
There is a saying in pashto that goes something like "success is sweating
and hardwork". In my case the sweat and hardwork is contributing, and being
criticized for my mistakes so I can change my way of thinking regarding the
particular concept in whose application I did a mistake in. Like again,
there are a billion ways to implement extended enums, but the ones used are
the ones that are made so let's make one.

On Sun, 26 Apr 2026, 3:26 pm Muneem, <itfllow123_at_[hidden]> wrote:

> Let's please talk about implementation:
>
> https://github.com/HjaldrKhilji/C-and-C-plus-plus-notes/blob/main/extended%20enum%20example
> https://onlinegdb.com/5raHnqV7e
> Like my code is not complete but please criticize it. My previous code had
> an issue with non constant expression being used but then I tried some
> fixes, so please tell me what you think. Like ideas are all good but I am
> really excited to see this idea work first. I know like I am new to all
> this so really haven't earned my seat at the table, but in my humble
> opinion, the design only makes sense when it's in the code.
>
> On Sun, 26 Apr 2026, 11:19 am Simon Schröder via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> > On Apr 25, 2026, at 7:38 PM, Marcin Jaczewski via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> >
>> > sob., 25 kwi 2026 o 10:03 Jens Maurer via Std-Proposals
>> > <std-proposals_at_[hidden]> napisał(a):
>> >>
>> >>
>> >>
>> >>> On 4/25/26 01:11, Sebastian Wittmeier via Std-Proposals wrote:
>> >>> They could have different underlying representations:
>> >>
>> >> Yes.
>> >>
>> >>> With strong typing the compiler could add an offset for one of the
>> ancestor enum classes.
>> >>
>> >> No, that won't work.
>> >>
>> >>
>> >> If this hypothetical feature is just for re-using enum values
>> >> and allowing conversion from a "base" value to a "derived" enum type,
>> >> then maybe there's some merit hidden here. However, I can't see how
>> >> to make a "Derived*" convert to a "Base*", similar to class derivation.
>> >>
>> >>
>> >> Alternative syntax suggestion:
>> >>
>> >> enum class Derived {
>> >> using enum Base; // import the enumerators here; ugh, semicolon
>> >> NEXT_ENUM = whatever,
>> >> };
>> >
>> > or maybe better would simply allow user-defined conversion functions
>> for enums.
>> > Then we could allow conversion from `Base` to `Derived`.
>>
>> Even if we can define conversion functions this would still leave the
>> problem that we would have to retype all enumerations of Base inside
>> Derived (and not forget that when we add one in Base later). As far as I
>> understand the main goal is to subsume all enumerations from Base in
>> Derived. Having *all* the enumerations is especially important when
>> switching over them (compilers give warnings when leave one out when using
>> enum classes).
>> >
>> >
>> >>
>> >> Jens
>> >>
>> >>
>> >>>
>> >>> -----Ursprüngliche Nachricht-----
>> >>> *Von:* Arthur O‘Dwyer via Std-Proposals <
>> std-proposals_at_[hidden]>
>> >>> *Gesendet:* Fr 24.04.2026 23:10
>> >>> *Betreff:* Re: [std-proposals] Add inheritance for Enum
>> Class enumerations
>> >>> *An:* std-proposals_at_[hidden];
>> >>> *CC:* Arthur O‘Dwyer <arthur.j.odwyer_at_[hidden]>;
>> >>>> On Fri, Apr 24, 2026 at 4:00 PM Gašper Ažman via Std-Proposals <
>> std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>> wrote:
>> >>>
>> >>> Note that `using enum` exists and probably does what you need.
>> >>>
>> >>>
>> >>> I don't think "using enum" does what Andrey wants — because I
>> think Andrey is trying to describe this other common problem instead. This
>> /r/ProgrammingLanguages thread <
>> https://www.reddit.com/r/ProgrammingLanguages/comments/rk1y4u/extending_enums/>
>> calls it "extending enums."
>> >>> Here's some lightly-anonymized code from a real (DNS-related)
>> codebase:
>> >>>
>> >>> enum HttpServerStat {
>> >>> TLS_HANDSHAKES,
>> >>> TLS_HANDSHAKE_ERRORS,
>> >>> TLS_HANDSHAKE_TIMEOUTS,
>> >>> [...]
>> >>> RESPONSE_DROPS,
>> >>> MAX_HTTP_SERVER_STAT_ID
>> >>> };
>> >>>
>> >>> enum HttpStat {
>> >>> // Extends HttpServerStat
>> >>> QUERY_COUNT_HTTP = MAX_HTTP_SERVER_STAT_ID,
>> >>> QUERY_BYTES_HTTP,
>> >>> RESPONSE_COUNT_HTTP,
>> >>> RESPONSE_BYTES_HTTP,
>> >>> [...]
>> >>> MAX_HTTP_STAT_ID
>> >>> };
>> >>>
>> >>> enum ODoHStat {
>> >>> // Extends HttpStat
>> >>> ODOH_QUERY_COUNT = MAX_HTTP_STAT_ID,
>> >>> ODOH_QUERY_BYTES,
>> >>> [...]
>> >>> ODOH_4XX_RESPONSE,
>> >>> MAX_ODOH_STAT_ID
>> >>> };
>> >>>
>> >>> (Sidebar: We had to make some very minor changes to the users of
>> this code for C++20, which tightened restrictions on cross-enum arithmetic
>> and comparison.)
>> >>> The idea is that ODoHStat "extends" HttpStat in the same way that
>> std::partial_ordering "extends" std::strong_ordering. Every value in the
>> domain of HttpStat is also in the domain of ODoHStat (although the reverse
>> is not true).
>> >>> Notice that this is the opposite of what class inheritance means!
>> When a /class/ ODoHStat /derives/ from HttpStat then we say that every
>> object of type ODoHStat is an object of type HttpStat (not the reverse).
>> >>>
>> >>> What we really want to be able to say here is something like
>> >>> enum class ODoHStat : using HttpStat {
>> >>> ODOH_QUERY_COUNT = MAX_HTTP_STAT_ID,
>> >>> ODOH_QUERY_BYTES,
>> >>> [...]
>> >>> ODOH_4XX_RESPONSE,
>> >>> MAX_ODOH_STAT_ID
>> >>> };
>> >>> Again, notice the inappropriateness of "inheritance" syntax here.
>> >>> enum ODoHStat : HttpStat { // NO!
>> >>> Because that syntax already has a meaning for enum declarations:
>> it's "HttpStat is the underlying type of ODoHStat; we guarantee that all
>> values of type ODoHStat will fit into an HttpStat." Which is /*not at all*/
>> what we mean here; in fact we mean the opposite: here we guarantee that all
>> values of type /HttpStat/ will fit into an /ODoHStat/.
>> >>>
>> >>> This fantasy feature would permit us to use `enum class`, and
>> expose all the enumerators of the "parent" enum as members of the "child",
>> thus:
>> >>> ODoHStat e = ODoHStat::QUERY_COUNT_HTTP;
>> >>> Today, we can't do that. We can either avoid scoped enums
>> altogether, or else we have to write
>> >>> ODoHStat e = static_cast<ODoHStat>(HttpStat::QUERY_COUNT_HTTP);
>> >>>
>> >>> If we got such a facility:
>> >>>
>> >>> (1) We would not want to permit the "child" enum to just start
>> listing new enumerators without an initializer for the first one:
>> >>> enum class ODoHStat : using HttpStat { ODOH_QUERY_COUNT,
>> ODOH_QUERY_BYTES, [...] // NO!
>> >>> because what would they start numbering at — zero?
>> one-more-than-the-parent-enum's-highest-enumerator?
>> std::bit_ceil-of-one-more-than-the-parent-enum's-highest-enumerator? None
>> of these are safe answers. The only safe pattern is as we do in the code
>> above: start where the parent enum tells you to start. Even then, this is
>> super fragile: if we add a new enumerator to HttpStat, that will increment
>> the values of ODoHStat's enumerators too. Arguably the author of ODoHStat
>> knew what they were signing up for when they used this facility?
>> >>>
>> >>> (2) The facility does not seem to permit "multiple inheritance,"
>> or if it does, the semantics might be surprising.
>> >>> enum class Fruit { Apple, Grape, Orange };
>> >>> enum class Color { Red, Orange, Yellow };
>> >>> enum class Thing : using Fruit, Color {};
>> >>> // both Thing::Apple and Thing::Red have value zero, right?
>> >>> // does Thing::Orange exist? what is its value?
>> >>>
>> >>> Anyway, I'm sure "extending enums" has been proposed before, but I
>> haven't yet found where. N1513 Improving Enumeration Types <
>> http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1513.pdf>
>> (2003) sketches several ideas re enums, but not this one.
>> >>>
>> >>> my $.02,
>> >>> –Arthur
>> >>>
>> >>> --
>> >>> 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
>> > --
>> > 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
>>
>