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
>