I want to simplify everything by avoiding going into circles(I don't want
to anger anyone by stretching the dough further) since I feel like my
proposal is complete(in concept) thanks to the immensely helpful feedback
that I received:
1. There is a huge different between restructuring to optimize and
introducing new mechanisms, optimization:
 requires you to either add extra cost(break the zero overhead principle)
or break ABI stability for that specific implementation.
New mechanisms:
Allow an implementation to change set(to fixed) a specific ABI for that new
construct, again, by doing so you aren't breaking existing code, you are
adding new items with new rules.
2. Xvalues aren't relevant(responding to Mr.Thiago) in decaying rules for
T^ into other types. Like are xvalues relevant for how a T can decay/be
passed as a T&& to a constructor of a class that only has T&&? Of course
not. Similiarly this is at the top of all that, and only has this simple
hirarchy:
T^ converts to(when T^ overload isn't present, and if any in the chain
isn't present then it's a compile time errors of course):
Const T^
Const T
T
Const T&
T&
Const T&&
T&&
//
For Const T^ is:
Const T
Const T&
Const T&&
Else of course compile time errors

The rest of the rules must remain the same, that's the main point.
2. My proposal has 3 new things:
1.A type_set<typename... Variadic> That instnatied into T^ for every T in
variadic. Now why would any guy be dumb enough to make a new construct T^?
To simplify rules! Without T^, what will
type_set<typename... Variadic>
Instnatiate into in so many contexts? Like one might pass it to a function
expecting const T&, so how do you quantify the exact rules of what's gonna
happen?
2. T^, T^ is glvalue in that it is stored in memory, but it's layout dosent
have to be like lvalue(a type of glvalue), but it still has to be fixed for
that implementation. Another unintended advantage that would booster this
for T^ is that in languages like python fixed sized heterogeneous
lists(tuples) can store multiple types, but you can't see it coming from
another function, that this element came from tuple, why is that an issue?
Well, say you accumulating the value in the heterogeneous list, now if you
stumbled upon a float, you might want to round it off or something before
adding it to the sum.
****(Philosophical part, skip if not interested)****
Another reason that makes more sense from a backend web developer is that
the heterogeneous list may represent a Key part of a SQL query that you are
preparing as an ORM that the outer system might access *from the list*.now
you want to see it as a program, but not let other threads/systems see it
because it might contain personal information that if not hidden from
everyone other than the core system would violate the legal right of the
user, so by providing overloads for T^, you handle that information when
being passed out of the core system through an overload and encrypt the
sensitive information. This might not seem like a lot but in these large
websites where you have a mess of large systems, where all you want to fix
a potential leak is a simple convinient overload.
3. A implementation defined container of type with a standard interface
with new mechanics
type_set<typename... Variadic>.
I will upload some code for the possible implementation of such mechanisms
in my response to Mr.Simon, it's c++ code that would rely on unions,
recursive inheritance of structs(similiar to types), and something similiar
to the dispatch code of Mr.sebistian. the goal of that is to try to
approximate how the syntax will look, even though you can't exactly avoid
using dispatch() functions unless a type_set<typename... Variadic> exists,
like you can even avoid it for move and copy, but never for normal function
calls or arethemtic, which will further booster the issues with the cracks
in the current ceiling of metaprogramming.


On Wed, 8 Apr 2026, 9:27 pm Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Wednesday, 8 April 2026 03:36:01 Pacific Daylight Time Muneem via Std-
> Proposals wrote:
> > I will email an extensive document describing how everything's assembly
> > code will look like
>
> Assembly isn't important at this stage. We need only the abstract machine
> and
> the language syntactic rules. You may use assembly to justify why the
> changes
> to the abstract machine and syntax must be done, but mind you that they
> are a
> weak justification because a sufficiently smart compiler could achieve
> them too.
>
> > 2. xvalues!? like I dont get it, like isn't an xvalue overloaded using
> T&&,
> > so the rules in point 1 should apply.
>
> Since C++11, we have had not 2, but 5 value categories:
>
> rvalue
> lvalue
> xvalue
> glvalue
> prvalue
>
> xvalues can "decay" into a glvalue or an rvalue. So, what are the rules
> for
> your new value category? Take a look at N3055 to see how it was proposed.
> See
> [basic.lval] for the current text. See [conv.lval] to see one of the
> conversion rules where you must insert yourself.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>