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 standard 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@hesbynett.no> 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.)