I had a mistake where each enum Hirearchy could only have one object, I
tried fixing it:
https://github.com/HjaldrKhilji/C-and-C-plus-plus-notes/blob/main/extended%20enum%20example
Again, this implementation can be wrapped up in more classes to hide the N
template paremeters of "enum wrapper complete" and allow multiple
inheritance. I will do all that tomorrow. This fix was something that I
remembered when I couldn't sleep, so I tried sleeping by thinking about cpp
that brought me to fix this. And again, I haven't tested by code, which is
something that I will do tomorrow.

On Sat, 25 Apr 2026, 7:30 pm Muneem, <itfllow123_at_[hidden]> wrote:

> I would like to clarify further that My example may not be the best but I
> hope we could move from abstract ideas to implementation.
>
> On Sat, 25 Apr 2026, 7:27 pm Muneem, <itfllow123_at_[hidden]> wrote:
>
>> Hi, guys!
>> Sorry, I am late to this great discussion ( I have been reading but also
>> working on a code example that I have yet to test):
>> https://www.onlinegdb.com/
>>
>> https://github.com/HjaldrKhilji/C-and-C-plus-plus-notes/blob/main/extended%20enum%20example#L1-L115
>>
>> Basically, I worked the whole day on this, so the goal was to like see if
>> such a technique could be used to implement the extended enums that you
>> guys are taking about.
>>
>> On Sat, 25 Apr 2026, 1:22 pm Sebastian Wittmeier via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> I was only concentrating on the combination, as the metaclasses were
>>> discussed.
>>>
>>>
>>>
>>> For convertibility of pointers along the inheritance chain, the Base
>>> pointer itself (probably not the object instance) has to keep the actual
>>> type.
>>>
>>>
>>>
>>> Or one leaves out pointer convertibility. Enums are a simple value type.
>>> We can't convert between int* and float* either. But we can assign
>>> values between them. Or create a std::variant. Such features can be useful
>>> for enums.
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Jens Maurer <jens.maurer_at_[hidden]>
>>> *Gesendet:* Sa 25.04.2026 10:03
>>> *Betreff:* Re: [std-proposals] Add inheritance for Enum Class
>>> enumerations
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>>>
>>>
>>> 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,
>>> };
>>>
>>> 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
>>>
>>