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