Noted with sorry. it's just that I was a little too excited with these
kinds of techniques. For me these changes aren't new updates but rather
documentation on the creation of newer stateful metaprogramming techniques,
but I do get your point, and I am sorry if I disturbed you or anyone else.

On Tue, Apr 28, 2026 at 6:56 PM Simon Schröder <dr.simon.schroeder_at_[hidden]>
wrote:

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