I will email an extensive document describing how everything's assembly
code will look like, from passing the heterogeneous, of course in practice,
its would be worse than what a implementation can come up with, but it
would be a good starting point, so give me some more time to compile many
examples.really Sorry for the inconvenience though, but I will make it
worth your while. The reason for the delay is that I want the assembly code
to be from what compilers are generating from structs instead of tuples or
array of variants while comparing them to the latter. I could write
arbitrary assembly code but that would be an inaccurate way to frame it.
meanwhile the response to your email is:
>What if it does? What if it does and the T&& doesn't? How about
cv-qualifier
mismatches?


>How about xvalues, where do they go?

>The overloading rules are *already* complicated. There's no way you can
add to
it without making it even more complicated. If you want to touch the
overloading rules *at all*, then you probably need to dedicate 5 years to
this
project. I am not kidding or exaggerating.
****ANSWER****
1. okay so T^ decays into const T, then T, then const T&, then so on.
Const/volatile T^ only decays into Const/volatile T, Const/volatile T&,
Const/volatile T&&.
2. xvalues!? like I dont get it, like isn't an xvalue overloaded using T&&,
so the rules in point 1 should apply.
3.they are hence I am providing a new value type, without this, any feature
for heterogenous lists would be hard to define, for example the dispatch
example of Mr. Sebistian was tiresome because what does it move when i try
to move a dispatch? what does it copy when I try to copy a dispatch, a
simple decaying rule list like in point one is all you need when dealing
with T^.

On Wed, Apr 8, 2026 at 8:09 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Tuesday, 7 April 2026 19:22:09 Pacific Daylight Time Muneem via Std-
> Proposals wrote:
> > No, I said it multiple times that T^ can decay into T& or T&& or even T
> if
> > T^ overload doesn't exist.
>
> What if it does? What if it does and the T&& doesn't? How about
> cv-qualifier
> mismatches?
>
> > You don't need that. The decaying priority list
> > is as follows:
> > If const lvalue overload is there then const lvalue, if lvalue overload
> > then lvalue, if const lvalue reference overload then const lvalue, and so
> > on (for rvalues as well). This priority list makes overloading for T^ fit
> > right into the existing overloading rules, without having to make
> > additional complicated overloading rules.
>
> How about xvalues, where do they go?
>
> The overloading rules are *already* complicated. There's no way you can
> add to
> it without making it even more complicated. If you want to touch the
> overloading rules *at all*, then you probably need to dedicate 5 years to
> this
> project. I am not kidding or exaggerating.
>
> --
> 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
>