1. The point was to allow book keeping information only if it is efficient.
2. Mixed types are not possible, since partial specializations of templates
for variadic paremeters of pointers/references to a type T depend on
specialization patterns. You could use enable if but in the case of say
variant<T, U&> the issue is that T and U& are not only different types but
one has a identity and the other is an alias, unlike pointers, references
don't have identities, like there identity is the object that they point
to, hence when you use &Obj where Obj is a reference, you get the address
of Obj instead of the reference's.



On Sat, 18 Apr 2026, 8:04 pm Sebastian Wittmeier via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> We have heard of no single bookkeeping from you which would improve
> performance. Probably there is none. So we should keep the types small.
>
>
>
>
>
> The thing with references inside (sum or product) of another type is that
> you have an indirection.
>
>
>
> The identity of the variant is differently to the identity of the
> reference inside the variant.
>
> They also have different types.
>
>
> You were asked about mixed types like std::variant<T1, T2&>
>
>
>
> Is such a type possible, how does it behave?
>
>
>
>
>
> A const variant cannot be reassigned. Isn't that enough?
>
>
>
>
>
> It could also be that a variant is not a perfect (from theory) sum type.
>
>
>
>
>
> All things to discuss in the paper.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Sa 18.04.2026 16:51
> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow runtime
> indexing.
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
> 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
>
> --
> 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
>