1.product type cant store bookkeeping information and the padding that they
do store is different since that is for aligning the whole structure to a
particular hardware. The padding is just the extra space of the box where
A,B,C, and other elements exist. ****WHY?****:
1. It breaks the zero overhead principle for the use case of a product type
which is compile time access. For example, if you have a struct and you
want to index it using reflections then the compiler can't just insert
bookkeeping information for you, as if it would break that principle.
2. tuples are s <https://stackoverflow.com/a/7189821/734069>tandard layout
and trivially copyable types, hence they cant include bookkeeping
information. In my example, a bookkeeping example could be variants stored
for indexes at each possible index, and since variants aren't trivially
copyable or standard layout, you can't do that.

On Sat, Apr 18, 2026 at 8:35 PM David Brown <david.brown_at_[hidden]>
wrote:

>
> On 18/04/2026 17:05, Muneem via Std-Proposals wrote:
> > 1."Tuples are product types" which means that they are meant to only
> > contain the objects that you store in them, which means that it can't by
> > defintion store book keeping information.
>
> You are misunderstanding the difference between the logical user-visible
> interface to a type, and the underlying implementation.
>
> If you have a vector of ints, then you can store a list of ints in it.
> But the actual implementation of the type will hold a pointer to the
> data, a count of the logical size, and a count of the allocated memory
> size.
>
> If you have a variant of an int and a double, you logically have either
> an int, or a double, but never both. The actual implementation of
> std::variant<int, double> will have space big enough to hold either
> type, along with an integer that holds an index showing which type is
> active.
>
> But you could have a different implementation of a variant that held two
> pointers - one of type int* and one of type double*. Only one of these
> would be non-null. It could have the same interface, and do the same
> job as far as the user is concerned.
>
>
> A tuple is a product type. That means if you have a tuple of an int and
> a double, then it can logically store an int /and/ a double at the same
> time. Whatever else the implementation may have - additional hidden
> fields in the underlying structure, additional methods beyond those
> documented, etc., are irrelevant to the logical definition and interface
> of the type.
>
> When you have a tuple of an int and a double, then you cannot store a
> char in it, or three ints, or anything other than an int and a double.
> But it does /not/ mean that the implementation of the type cannot have
> additional information - bookkeeping data, if you like.
>
> In C++, even fundamental types can have extra space - blank fields that
> exist in the implementation, but have no logical meaning. While
> implementations with padding bits in integer types are quite obscure,
> "bool" types generally have 1 value bit and 7 padding bits. These are
> logically only able to store "true" or "false", but have 7 extra
> "bookkeeping" bits.
>
> (Typical implementation of std::tuple<> in C++ standard libraries will
> not have any additional fields or data, beyond any padding needed for
> alignment. But they are allowed to do so.)
>
>
>
>