Please be respectful of other people's time. For the general discussion of
standardization it doesn't matter if you find it hard to implement or if it
takes a little longer to implement (or if you have to go to sleep). In
general, people on this list will first implement the whole thing and once
it is done they post their solution. It doesn't matter if it takes a month.
This is not a chat.

If you keep posting tiny updates you run the risk that at least some
readers of this mailing list will skip your contributions when they see
your name as the sender. If you want the best feedback you need to send
less often (don't send updates how it is going, but send something when it
is finished). We are not here to cheer you on.

And in general for your emails: I would be good if you just saved it to the
drafts folder and reviewed it an hour later. I expect your responses to be
much better and waste less of other people's time (though I might be wrong
on this).

On Tue, Apr 28, 2026 at 3:28 PM Muneem via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I am sorry if I am disturbing, but I just wanted to show that my main code
> is done (only a little is left to be completed for the basic use to be
> compiled). I will do the rest tomorrow but yeah, the pattern is
> beautiful but a little costly though (the complexity in practice shortens
> as the data grows). I am sending this email because I enjoyed making this
> and I think that you guys will as well, and that you guys will see the
> beauty of this pattern:
>
> https://github.com/HjaldrKhilji/C-and-C-plus-plus-notes/blob/main/extended%20enum%20example
> https://onlinegdb.com/8tt9dxa6c
>
> On Tue, Apr 28, 2026 at 9:37 AM Muneem <itfllow123_at_[hidden]> wrote:
>
>> I was just trying to make some conversation, like the scope of these kind
>> of tricks is a lot. We can literally change metaprogramming if we can allow
>> inheritance like behaviour that is not only lightweight but in practice
>> feels like a built in type. Showing the process was to like show that while
>> it is hard and you will hit wall, it is not impossible, even for me. I do
>> get that I should've made it short and way fewer emails, but yeah, I will
>> do that from now on.
>>
>> On Mon, 27 Apr 2026, 10:57 pm Sebastian Wittmeier via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> I think this list is not good for giving frequent updates on
>>> implementations of features, especially not central for understanding or
>>> especially if the implementation is not finished.
>>>
>>>
>>>
>>> If Andrey Fokin directly wants to work on an implementation, you can
>>> coordinate.
>>>
>>> But frequent implementations updates is (IMHO) a bit too noisy here.
>>> Some other posters have done the same and got respective feedback.
>>>
>>>
>>>
>>> Not to curb your enthusiasm, just to focus your emails better. And all
>>> is in MHO.
>>>
>>>
>>>
>>> Sebastian
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Mo 27.04.2026 18:59
>>> *Betreff:* Re: [std-proposals] Add inheritance for Enum Class
>>> enumerations
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Muneem <itfllow123_at_[hidden]>;
>>> Sorry for obsessing too much over the implementation and sending too
>>> many emails. I am obsessed with this enum inheritance support because any
>>> technique of allowing stateful metaprogramming should be treasured, as long
>>> as it's not one of those wierd freind injecting techniques. In my case, I
>>> am checking is a specialization exists, to find a unique number which I use
>>> to stack static constexpr enums. Each class specializations has its own
>>> stack of these enums. If I manage to make this enum inheritance work then
>>> maybe we will have a time where you can feed "nueral network"/prediction
>>> paremeter data through compiler paremeters, and use the values and types of
>>> say these enums with hirearchies, to make decisions on what the type and
>>> data of later enums objects that are in a Hirearchy should be. Basically,
>>> it could allow for lightweight compile time polymorphism. The technique
>>> looks like this to get a number:
>>> template<template<std::uintmax_t N_> class C, std::uintmax_t N>
>>> struct exist {
>>> template<typename exist_if_exist=
>>> decltype(std::declval<C<N>>().~C<N>())>
>>> bool static does() {
>>> return true;
>>> }
>>> bool static does() {
>>> exist<sequential_count, N+1> dummy{};
>>>
>>> return false;
>>> }
>>> };
>>>
>>> namespace {
>>> template<std::uintmax_t N=0>
>>> struct sequential_count {
>>>
>>> consteval static std::uintmax_t get_num() {
>>>
>>> if(exist<sequential_count, N+1>::does()) {
>>> return sequential_count<N+2>::get_num()
>>>
>>> }
>>> else {
>>> return N+1;
>>> }
>>> }
>>>
>>> };
>>>
>>> }
>>> Once you have a number, you could use that to get a new type for that
>>> specific class Hirearchy object. Each object has its own hirarchy cuz each
>>> object has a default argument that gets a unique number this way. You could
>>> add a wrapper that basically does the same as get_num but instead it checks
>>> if N*b exists and if it does then: return N*b if N*b minus 1 does not exist,
>>> Else if N*b-b does not exist then call a linear search that returns
>>> N+linear_search,
>>> else return N+the_whole_process_from_n_being_1.
>>> The goal is to expand metaprogramming into something with state.
>>>
>>>
>>> On Mon, 27 Apr 2026, 4:08 pm Muneem, <itfllow123_at_[hidden]> wrote:
>>>
>>> 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
>>>
>>> --
>>> 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
>