On 27 August 2023 19:25:56 BST, Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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