Re: std::pair copy and move constructor

[Daniel Krügler <daniel dot kruegler at gmail dot com>]

2013/2/16 François Dumont <frs.dumont@gmail.com>:
> On 02/15/2013 10:00 PM, Daniel Krügler wrote:
>>
>> 2013/2/15 François Dumont <frs.dumont@gmail.com>:
>>>
>>> Hi
>>>
>>>      I had a problem with the result of
>>> std::is_copy_assignable<std::pair<const int, int>>::type which used to be
>>> true_type. So here is a patch to fix that.
>>
>> This patch would break with the requirements of the library. In
>> particular it would prevent that std::pair's of references are
>> copy-assignable and that exactly is the purpose for the user-provided
>> copy-assignment operators of pair (and tuple).
>
>
> I knew there must have been something.
>
> Is there a test showing this problem ?

I would expect that the following code would no longer be accepted:

#include <utility>

int main() {
  int i{};
  int j{};
  std::pair<int&, int&> pii1(i, j);
  const std::pair<int&, int&> pii2(i, j);
  pii1 = pii2;
}

because with a defaulted copy-assignment operator, std::pair<int&,
int&> would have a deleted copy-assignment operator.

> Cause I see no regression with this
> patch. Add having std::is_copy_assignable<std::pair<const int, int>> being
> true_type is a problem, no ?

It is very unfortunate, but I see no good way to prevent it.
Technically one could consider to restructure std::pair to have a base
class and to use a base-class tagging technique to mark the
copy-assignment operator of the derived class as deleted, when the
members don't satisfy the constraints (modulo references, of-course).
See

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043#c17

for the idea that I could imagine of, but that is completely untested
at the moment. To my knowledge this approach has now been implemented
for std::unordered_map in regard to a similar problem (as described in
the referenced issue) and I used it when I implemented something like
an optional type where I wanted to realize a similar thing.

- Daniel