Correction (sorry for my mistake):
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&
//
For Const T^ is:
Const T
Const T&
Else of course compile time errors

No implicit conversions to rvalues references without std move just like
for ordinary T which require std::move (sorry for the error in my last
email)

On Thu, 9 Apr 2026, 12:04 pm Muneem, <itfllow123_at_[hidden]> wrote:

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