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