My response to Thiago Marciena: for it to remain an implementation details
while maintaining ABI stability, you need new constructs. Like I can't move
something from underneath without expecting a whole structure to fall
unless nothing is at the top. In this case, the structure is the code that
already exists, so you don't want to break that, and without breaking that,
you can optimize. Again, why do flat maps exist, why don't we all optimize
maps away if the compiler can figure out that the constant latency of a
flat maps is actually gonna be faster.

On Fri, 10 Apr 2026, 5:10 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thursday, 9 April 2026 12:58:56 Pacific Daylight Time Sebastian
> Wittmeier
> via Std-Proposals wrote:
> > std::tuple is one element after the other, with some padding for correct
> > alignment. (in some standard libraries in reverse order of elements)
>
> A smarter implementation would sort them in decreasing order of alignment
> requirements so as to avoid intra-object padding and thus decrease the the
> total object size.
>
> Whether that is doable without undue compilation time is unknown. It was
> most
> likely not doable with compilers of 2010 when std::tuple was first
> introduced
> into the libraries. libc++, because it came late to the party, has a few
> techniques that hadn't occurred to the developers of older
> implementations,
> which now can't be fixed due to ABI.
>
> However, the point is that this is an *implementation detail*. The
> language
> does not impose the order, or the ABI for that matter.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>