The thing about c++ is that most invariants and behaviours of types are
very mathematical. For example, Bjarne Strourstrup groups containers as
open sequences and half open sequences. Associative containers are open
sequences, while the others are half open. Similarly the spaceship operator
exists for that mathematical symmetry to exist. Again, if you read the ISO
cpp manual, you would start to realize that a lot of it feels like an
extension to some branches of mathematics in some way. The point is that
you need well defined types with well defined behaviour in the standard. I
can claim or make rules about the type variant<T&...> but I want to back
them using mathematical notions. Programming is the field of reasoning
about process and to reason about process you need to do using imperative
facts, which is in this case mathematics. What makes C++ good is the
philosophy of bjarne stroustrup.

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

> 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]> 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]>
> *Gesendet:* Sa 18.04.2026 16:24
> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow runtime
> indexing.
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <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]> 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
>
> -- 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>