My "extended enums" when complete could be equavilent to constexpr normal
enums, like normally the input to enum is constexpr anyway so this should
be okay. One could further provide more functions that if the enum is
runtime initliazed or Assigned at runtime then the return value is a simple
uintmax_t or another variant. Once the code is finished, I would try to do
that and also show an example of how to implement multiple inheritance on
it.

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

> 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
>>>
>>