On Sat, Aug 26, 2023 at 1:38 AM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Il 25/08/23 17:07, Hewill Kang via Std-Proposals ha scritto:
> > I wonder if we could get this compression optimization at almost no cost
> > if add the C++ |[[no_unique_address]]| attribute to the members of
> > |std::pair|:
> >
>
> Rather than a breaking change, why not proposing to add
> std::compressed_tuple -- a tuple that is guaranteed to implement this
> optimization?
>

The problem I see is that there is an unknown infinity of "optimizations"
we might want to add to pair/tuple, and each one of them is an ABI break.
We can't just keep inventing new names forever; at some point some vendor
must take the plunge and break ABI (and/or drop support for old C++
revisions).

Barry already mentioned:
- make tuple<T> trivially copyable when T is trivially copyable
- make tuple<T> trivially destructible when T is trivially destructible
(etc.)
I would add:
- make tuple<A,B> minimal-size when A would fit in B's tail padding but not
vice versa
(this can be approximated by sorting the Ts... by alignment; no vendor
implementation does even this much today)
- make tuple<A,B> trivially equality comparable when possible
(I think this is not a further ABI break; it just constrains the possible
packings of Ts... in the case that the resulting tuple has no padding)

I think you could even conditionally swap the order of `pair.first` and
`pair.second`, since `pair` is only pretending to be an aggregate; right?
(Again it would be an ABI break, but not an *API* break, unless I'm
mistaken.) Because `pair p = {first, second}` actually calls a constructor
and `auto [first, second] = pair()` actually invokes std::get. I guess
there might be some guarantees about `pair<A,B>` being
pointer-interconvertible with `A` which would break if someone did that,
though.

my $.02,
Arthur