On Fri, 17 Apr 2026, 04:57 Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thu, Apr 16, 2026 at 10:26 PM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Abstract: This proposal provides a specialization of std::tuple that can
> be indexed at runtime. It also introduces specializations for std::variant
> and std::optional to ensure the interface of such a tuple remains efficient.
> > I wrote 3 files, the first was a complete draft that I am gonna paste as
> a txt file, the second was a formatted docx file that I wanted to float
> around the internet to get some feedback before I post it over here (sadly
> no on was interested in the poor man's document), and the third is the
> shortened version where I removed all the code and kept it conceptual.
> Sorry for pasting three files at once, but I just wanted to see which one
> is acceptable and which one isn't. Personally, I like the first two.
>
> Your proposal is full of key statements that you say confidently, as
> if they were self-evidently true, but you offer no evidence for it
> (anecdotal or otherwise). And these aren't minor nit-picks; they're
> *foundational* to the choices your proposal makes.
>
> For example:
>
> > Existing tuples cannot be optimized for runtime indexing without
> breaking ABI (Application Binary Interface).
>
> Where's the evidence for it?
>
> A tuple is just a struct that uses compile-time numeric indices
> instead of compile-time names. If you use a compile-time name or
> compile-time index, this is converted into an address within the
> "struct". For every struct member, there is a byte offset from the
> start of the struct to that member.
>
> The thing that determines what the byte offset is for a given member
> is the implementation of the tuple/struct. This is baked into the ABI
> of the object. Which means that the *only part* of this process that
> is in any way ABI dependent is the specific mapping from an index to a
> byte offset..
>
> Your hypothetical runtime-optimized tuple would also have a way to
> convert an index into a byte offset. Every member would have a
> separate byte offset. So... why would one mapping of index:byte-offset
> be inherently slower at runtime than a different one? Why does ABI
> matter *at all* for converting a runtime index to a byte offset?
>
> The veracity of your statement is the core reason why your proposal
> uses a `tuple` specialization. That is, if this statement is untrue,
> then there's no reason to not just allow any `tuple` to be able to use
> runtime indexing.
>
> So if you're going to make that a part of your proposal, it needs to
> actually justify this statement.
>
> Similarly:
>
> > This also means common implementations of variants (tagged unions or
> "closed set unions") might not suffice. Instead, implementations should use
> techniques similar to typeid or other internal mechanisms.
>
> Um... why not?
>
> A reference is just a pointer. A variant of references is really just
> a variant of pointers. And pointers are all the same size.


That's not guaranteed by the standard.

Pointers to classes can be a different size from char*, and pointers to
functions can be a different size too.