1. I am sorry for misinterpreting your example (I understand it now but
previously my Brian kept on assuming things since your code was like
something that I haven't seen in my life, like I thought it was pure
incomplete pseudo code that I am really bad at interpreting). The first
thing with your example is the same that you construct variants on the fly
at runtime which leads to some but neglible overhead.
The second real issue is that while your list of indexes avoids modifying
another tuple with the same specialization, it does however:
1.lead to additional indexing than just one indexing into an array. (Not a
big deal of course)
2. Break the zero overhead principle by allowing tuple specializations to
have extra data. (Debatable)
3. The main point is that while your code gives you useful insight in how
my code can be more space efficient while sacrificing just a few potential
cycles, it is an incomplete solution, since it limits the compiler to just
one kind of book keeping information. For example, a smarter implementor
might imagine that by storing objects and the corresponding variant<T&...>
Together, since getting the reference will also get the object and this is
very relevant for large objects. Infact, I will try to implement it (just
make the tuples be a pair containing T and a variant, then initialize the
bookkeeper will references_wrpaper/pointers to those variants, the
subscript will simply index the book keeper and get the variant and return
it) and post it Tomorrow. The main goal for a new tuple is to allow any
kind of object layout and ABI structure since std::variant<T&...> Is new,
and the runtime indexed tuple type would be new.
4. The issue with global lifetimes(lack of a better word) objects is that
they don't have the same "stack locality"(lack of a better words), which
can again leads to slower speeds, not only because of the data is far away
from each other but also because compilers often have a harder time
optimizing variables with long lifetimes (Debatable point ofcourse because
I am not a compiler expert).
5. The issue with having a separate type for storing index based book
keeping still applies that there is too much boilerplate ,and that the code
isn't exactly flexible and/or totally up to the implementation.
6.The main goal isn't a single type of layout but any kind of layout. My
updated code will show a cache friendly type where the book keeping
information of the variant and the object itself is in the tuple, and the
book keeping array is just containing pointers to the actual book keeping
information. It will show how many potential ways really are there when the
compiler has complete freedom.

(Again really sorry for misunderstanding your code, I am just bad at
reading pseudo code,like my mind freaks out since in o levels(high school),
the course encouraged it and I hated the o levels computer science syllabus
cuz of technical mistakes. Hope you don't mind it)

On Mon, 20 Apr 2026, 6:11 pm Simon Schröder, <dr.simon.schroeder_at_[hidden]>
wrote:

>
>
> On Mon, Apr 20, 2026 at 1:56 PM Muneem <itfllow123_at_[hidden]> wrote:
> 2. Multiple tuples with the same T... (In others: Same specialization)
> Could then share the same book keeping information, leading to a
> modification to one resulting in modification to all.
>
> I don't understand this. Every std::tuple<int,float,std::string> has
> exactly the same offsets (not addresses!). You cannot modify the types that
> are stored inside a tuple. The offset information is fixed. For a specific
> set of Ts... the offset for every index is fixed. Nothing will change. It
> is just the offset, not the address, and not the value. This is the basis
> of any ABI for a std::tuple: Knowing the offsets of each element inside the
> tuple.
>
>
>> 3. The offsets cant be the same exactly because duplicates will exist, so
>> you can try to make them stable to a certain extent but you can't exactly
>> do that, since tuples can and should have two objects of the same type but
>> a variant can't have two same types according to the current c++ standard.
>>
>
> Offsets are according to the index and not according to the type.
> Duplicate types are not a problem at all. If you would've read the few
> lines of codes I actually posted, you would have seen that I create the
> std::variant as part of my return statement from the offset. In contrast to
> your solution I don't have an array of variants for bookkeeping. I also
> don't think that this is a drawback of this approach (having to construct
> the variant).
>
>
>> 4.I am not breaking the ABI of existing tuples, infact I am proposing a
>> new type. I used the name tuple to make my code shorter and readable.
>>
>
> I was just showing that it is possible to write an efficient solution with
> the existing std::tuple without breaking ABI. I don't consider new
> additional types in the language an advantage if an existing type can do
> the same with only minor adjustments (especially if the optimal solution
> does not have to break ABI). Fewer types are easier to teach.
>
>
>> 5. The issue with adding a new type is too much Boilter plate because you
>> would have to use that and annoying hardwork to keep track of which object
>> of that type corresponds to which tuple, this hardwork if not done well can
>> lead to undefined behavior if you use the wrong book keeper with the wrong
>> tuple.
>>
>
> In my example tuple_bookkeeper is just identified by the exact same
> template parameters as the tuple itself. There is again one
> tuple_bookkeeper for a specific set of Ts... storing the *offsets* and not
> an array of *variants*. It is in fact really easy to find the correct
> bookkeeper based on the type (and it would be hidden inside the standard
> library anyway). This type would not be standardized, but could be one way
> to implement storing offsets without having it inside the std::tuple.
>
> All your concerns only apply if we have an array of variants for
> bookkeeping. As long as operator[] returns std::variant (value) and not a
> std::variant& (reference) there is no advantage of having the variant ready
> (with offsets we call a regular constructor, with variants in bookkeeping
> we are calling a copy constructor).
>