1. I am not stating that book keeping is obligatory, but rather the
implementation has that choice to make, and as we know the implementation
knows more than us.
2. the layout can change based on a standard tag : std::tuple<T...,
std::runtime_index_tag> or std::tuple<std::runtime_index_tag, T...>, this
is because the std namespace is reserved for the standard library, so you
yeah, if anyone were to defined std::runtime_index_tag and then use
std::tuple<std::runtime_index_tag, T...>, he would effectively turn his
program into a ill formed program. read this
https://en.cppreference.com/cpp/language/extending_std for a more
trustworthy source on why the std namespace is reserved.
3.Again, having bookkeeping information in the tuple is completely optional
for the implementation based on what it thinks is most efficient for
runtime indexing.
4. while allowing runtime indexing, all the user should care about is a
stable non changing interface or not because believe me or not, I thought
that using pointers is actually efficient as it can help me save space(4
years ago), and that may or not be right, so what I would rather want is
the implementation to handle that for me. Runtime indexing is something
that should not be related with space or time constraints but rather be a
nice balance between them.

On Fri, Apr 17, 2026 at 6:24 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>