[cfe-dev] std::pair not trivially copyable?

[Richard Smith via cfe-dev]

On Wed, 26 Aug 2020 at 10:18, Nevin Liber via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Aug 25, 2020 at 4:37 PM David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>> From what I can tell, reading this (
>> https://stackoverflow.com/questions/58283694/why-is-pair-of-const-trivially-copyable-but-pair-is-not )
>> and the C++17 spec, it just doesn't specify the copy and move assignment
>> operators as defaulted, or say anything about their triviality, so they
>> aren't trivial even for trivial types. Perhaps an oversight when thinking
>> about the other complexities of when they shuold be deleted.
>>
>
> In general, move/copy assignment cannot be defaulted for pair, because
> assignment of reference types has meaning:
>
> int i = 2;
> int j = 3;
> std::pair<int&, int> p1(i, 5);
> std::pair<int&, int> p2(j, 7);
> p2 = p1;  // j now has the value 2
>
>
> struct A
> {
>     A(int& r_, int i_) : r(r_), i(i_) {}
>     int& r;
>     int i;
> };
>
> int i = 2;
> int j = 3;
> A a1(i, 5);
> A a2(j, 7);
> a2 = a1;  // Compile time error - deleted copy assignment operator
>
>
> Now,  this doesn't that pair couldn't have trivial copy/move assignment
> operators when it holds trivially copy/move assignable types, but I don't
> know how much of an ABI break this would be.
>

Making std::pair be trivially-copyable whenever possible would affect
whether std::pair is POD for the purpose of layout, which could result in
an ABI break for at least any code that derives from std::pair or that
contains a [[no_unique_address]] std::pair member:
https://godbolt.org/z/GTvo4r

This is certainly not something we could do for the libc++ stable ABI.
Maybe for the unstable ABI, but given the above change only makes layout
worse, it's not clear that there would be a strong motivation. We already
give std::pair trivial copy/move construction and trivial destruction
whenever possible, so we can pass and return it efficiently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200826/0857327e/attachment.html>