1. Sorry if my previous responses were unclear
2. In simple words: the deticated type is a sum type of multiple reference
types. Sum types by defintion should obey the core behaviour of the types
inside it. Say for a T or T*, the invariant and behaviour for both of them
is to have an identity and this semantics to remain valid. Hence a variant
would make sure that it dosent destroy their identity by itself or does
anything that harms it's invariant. The behaviour of a T& is to be a
reference to a particular object and to never change, that's the main thing
that it does, hence a sum type of a reference should technically be a
reference to a single object for it's entire lifetime.conceptually: Just
like a reference wrappers.

I don't want to talk about performance because the standard dosent deal
with that. It deals with gurranties. All that I can talk about performance
is that tuples are product types hence they're goal is to be that. They
cant be optimized with extra book keeping information that can be useful
since that breaks the notion of a product type since product types should
only contain objects that it holds. Performance boost on a standard level
happens by producing completely new notions with no Baggage what so ever. I
talk about bjarne Stroustrup, just to remind you of a baggage and because I
am trying avoid talking about anything that I assume and instead back
things up with basic terms and some references.

On Sat, 18 Apr 2026, 6:57 pm Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Sat, Apr 18, 2026 at 9:21 AM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > 1. The "dedicated type" is variant<T&...> That I proposed. It is a
> problem because a tuple elements is supposed have a single type (non
> reference variants final).
> > 2. I am not repeating words, all I am saying is that runtime indexing a
> heterogeneous list requires a new type. That type is runtime_indexed_tuple.
> The reason, you can't use existing tuples is that they have a fixed ABI for
> every specialization, hence you have to work with the overhead of that
> tuple, while in my cass, the implementation can have its own completely new
> ABI. No one should reinvent the wheel twice, especially blocks that aren't
> optimized for that wheel, which in the case of Sebastian's example was the
> variant of pointers and the tuple.
>
> This may sound insulting, but do you know what it means to provide
> evidence for something?
>
> If you own a car, and you're driving it, then you're pulled over and
> asked to provide evidence that your vehicle is registered to you, you
> could say that registration is a legal framework that exists and that
> it's a real thing. You could explain that we as a society have all
> agreed that registration is good, and that societies that don't have
> that aren't as good as ours. You could even cite laws and the specific
> debates on the subject.
>
> But none of that is evidence that *your* vehicle is registered *to you*.
>
> That's the kind of thing we're asking for.
>
> A philosophical diatribe on the importance of optimization and example
> cases where improved performance required a new type is *not*
> answering the question being asked. Citing philosophers on the nature
> of programming is not answering the question being asked.
>
> You are being asked why *your* specific proposed type needs to be a
> new type instead of a `std::tuple`. An answer to that question needs
> to look at the performance of your theorized code using `std::tuple`,
> and then look at the performance of your theorized code using your
> `runtime_tuple`. The answer must be a practical statement based on
> observable, independently verifiable evidence about this specific
> type.
>
> And if you're not going to provide that because you don't think you
> should have to, then you need to at least explain why it is that you
> don't think you should have to.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>