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