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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> > wrote: > On Apr 25, 2026, at 7:38 PM, Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: > > sob., 25 kwi 2026 o 10:03 Jens Maurer via Std-Proposals > <std-proposals_at_[hidden] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; >>>    *CC:*     Arthur O‘Dwyer <arthur.j.odwyer_at_[hidden] <mailto: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]> <mailto: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 <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] <mailto:Std-Proposals_at_[hidden]> >>>     https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >>> >>> >>> >> >> -- >> Std-Proposals mailing list >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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