I did finished till here for today ( a lot still left ):
https://onlinegdb.com/AUyKksvtW
https://github.com/HjaldrKhilji/C-and-C-plus-plus-notes/blob/main/extended%20enum%20example
Credits to:
https://www.lukas-barth.net/blog/checking-if-specialized/
For helping me find a technique to see if a type has been instantiated or
not, which really helped me to like do the stateful metaprogramming thing.
Unlike the unfortunate "get obj" technique, this one will hopefully work!

On Mon, 27 Apr 2026, 1:53 pm Muneem, <itfllow123_at_[hidden]> wrote:

> Looks like my consteval workaround to get a static class data member to be
> constant dosent work. It's a shame but I will find a technique, it's just
> this one thing. Sorry for the delay, like I get this should've been
> trivial but sometimes you gotta hack into the language, which isn't as
> straightforward as I thought it would be.
>
> On Sun, 26 Apr 2026, 6:32 pm Muneem, <itfllow123_at_[hidden]> wrote:
>
>> In case anyone is confused by my ad hoc pattern: it's basically stateful
>> metaprogramming such that each enum object has a new type. This stateful
>> metaprogramming technique is (for the lack of a better word) "Appending
>> pattern":
>> //it looks something like this:
>> //This pattern wont cause issues in multiple translation units because
>> you are basically appending and the part where you create the "red
>> apple"(the part where the data exist) is when you append. Since the
>> appending(not overwriting) part is literally spending hence there should be
>> no issues.
>> template<typename T, T* obj>
>> consteval T get_obj() {
>> return *obj;
>> }
>>
>> template<typename T, std::uintmax_t N>
>> struct The_red_apple{
>> inline static bool v = false;
>> inline static T data;//get_obj can also be used to pass this as a
>> template argument
>> };
>> template<typename T, std::uintmax_t N=0, bool v=get_obj<bool,&
>> type_exists<T, N>::v>()>
>> struct get_the_type{
>> using type_found=
>> std::conditional_t<
>> v,
>> typename get_the_type <T, N+1>::internal_t,
>> The_red_apple <T, N>
>> >;
>> type_found ::v= true;// the type was already appended hence no
>> issues (like no issues of overwriting an existing type's static data)
>> static const constexpr std::uintmax_t N_val= N; //could be used further
>> down the tree just line in my original (but incomplete code).
>> //sorry if my original code (since it was incomplete) made this simple
>> pattern look ad hoc and bad
>> }
>>
>> On Sun, Apr 26, 2026 at 4:07 PM Muneem <itfllow123_at_[hidden]> wrote:
>>
>>> 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
>>>>>>
>>>>>