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).