On Sat, Aug 26, 2023 at 1:38 AM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> 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