You can create a const std::variant<T&, ...> vs. a std::variant<T&, ...>, then you have whatever the user needs.   In other languages there are references with reassignment and without.   In other languages there are product types with additional internal data and without.   And I mean functional languages, which typically are nearer to the theoretical foundations of type theory.   Those are all good arguments for a proposal paper, but don't expect to have a type-theoretically perfect language. C++ isn't. And even type theory is not clear on those points above.     -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 18.04.2026 17:06 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; 1."Tuples are product types" which means that they are meant to only contain the objects that you store in them, which means that it can't by defintion store book keeping information. 2. Sorry for misunderstanding your const variant with variant of const. 3. Const variant would imply that the = operator is not gonna be available (in the case of variant of  T...) and that the value can be NULL in the case of variants of T*...  , both are unacceptable for a reference to an element in a tuple. On Sat, 18 Apr 2026, 7:44 pm Sebastian Wittmeier via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Why is a runtime indexed tuple not a product type? What does it matter how the tuple is accessed?   Again: const std::variant cannot change the type. It is not the same as variant of const.   -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet:Sa 18.04.2026 16:24 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; CC:Muneem <itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]> >; 1.Unions of references or variants of references is a new concept,  but references aren't, and because reference are literally aliases to an object, hence union/variants of reference should be too. To prove my self up, let's look at what a variant is conceptually.......: sum type, which is a kind of algebraic type, where as a reference type is a "value that enables a program to indirectly access a particular datum",  sum types are sort of a UNION of types, which means that they have to preserve the core behaviour of their type. For some T, the core behaviour is to have a identity, its own invariant, and semantics. For some T*, it's the identy of the pointer and the semantics of the pointer. For a references, it's pointing to an object and that object only, So by using const &, you are just making the other object that is being pointed to as constant, not the reference itself, since the reference is comstant pointer to an object. More formally, you could a "A reference is a value that enables a program to indirectly access a particular datum".  2. What I meant, by "tuples have overhead" is that they have a fixed ABI for all their specaizations, which means that any book keeping has to be on the top of the tuple and can't be inside it. Since runtime indexed tuples are a completely different notion than compile indexed tuple since one is a product type like a struct. Runtime indexed tuples is heterogeneous list. A product type is not a product type if it has anything other than the objects of the multiple types it holds. Reference: https://en.wikipedia.org/wiki/Algebraic_data_type    On Sat, 18 Apr 2026, 6:32 pm Thiago Macieira via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Saturday, 18 April 2026 06:21:07 Pacific Daylight Time Muneem via Std- Proposals 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). But you didn't explain why a variant of references must be final & const (cannot be reseated). You've said it has to, but not explained why. > 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. Except that std::tuple has zero overhead: it has exactly the bits required to store the types in the type list, maybe some padding that can't be avoided, and no more. How can you make a type with less overhead? Did you mean one with more overhead that simplifies some other task by keeping other information? You need to explain why it's needed and what the trade-offs are. -- Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> - thiago (AT) kde.org <http://kde.org>   Principal Engineer - Intel Data Center - Platform & Sys. Eng. -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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