On Fri, Apr 17, 2026 at 4:52 AM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> The bookkeeping for example could be initializing a std:: variant<T&...> For every T in the T... Passed to the tuple as a template argument, and storing them in an array. The subscript would simply index and return any of them.

Here's the problem. Doing what you propose is equivalent of defining a
struct where every member also has a second member that is a pointer
to that element. That represents a memory vs. performance tradeoff:
you're bloating the data layout of the runtime tuple in exchange for
reducing the cost of getting the variant (in theory; I genuinely don't
believe this would ever be a performance problem in practice, but
let's pretend).

The bigger problem with this is that how much of an overall
performance boost this gives is *not* something that a compiler could
ever optimize for. For one thing, the data layout cannot be changed;
whether it has these internal pointer or not is a part of the class
itself. For any given `runtime_tuple<Ts...>`, it will either always
have internal pointers or it always won't. That's baked into the
implementation and its chosen data layout.

But whether those internal pointers are worth the bloat depends on the
access pattern of the object. That is, how much you use runtime
indexing vs. copying/storage/cache misses/etc. The compiler *cannot*
know that because it's ultimately based on information compilers
cannot have.

Put simply, whether `runtime_tuple<int, float>` should be 24 bytes
instead of 8 bytes depends entirely on the how a particular user uses
it. One user might not index enough to make the extra 16 bytes of
storage worth having, while the other person might. This decision must
be made by the user; it cannot be made by the compiler, since the
compiler must pick one or the other at instantiation time.

So if the performance issue you're talking about actually exists,
you'd need two types to allow the user to pick whichever is higher
performance for their use case at that time.