Proposed resolution:

Add the following declaration [pairs.pair], before the declaration of pair& operator=(pair&& p);:

template<class U, class V> pair& operator=(const pair<U, V>& p);

Add the following description to [pairs.pair] after paragraph 11 (before the description of pair& operator=(pair&& p);):

template<class U, class V> pair& operator=(const pair<U, V>& p);

Requires: T1 shall satisfy the requirements of CopyAssignable from U. T2 shall satisfy the requirements of CopyAssignable from V.

Effects: Assigns p.first to first and p.second to second.

Returns: *this.

[ 2010 Pittsburgh: Moved to Ready for Pittsburgh. ]

[ 2010-03-11 Stefanus provided wording. ]

[ 2009-07 Frankfurt ]

We agree with the intent, but we need to wait for the dust to settle on concepts.

[ 2009-05-25 Alisdair adds: ]

Issue 885 was something I reported while reviewing the library concepts documents ahead of San Francisco. The missing operator was added as part of the paper adopted at that meeting (N2770) and I can confirm this operator is present in the current working paper. I recommend NAD.

[ post San Francisco: ]

Possibly NAD Editorial, solved by N2770.

[ San Francisco: ]

Would be NAD if better ctors fixed it.

Related to 811.

20.2.3 pairs
Missing assignemnt operator:
template<class U , class V>
  requires CopyAssignable<T1, U> && CopyAssignable<T2, V>
    pair& operator=(pair<U , V> const & p );

Well, that's interesting. This assignment operator isn't in the current working paper, either. Perhaps we deemed it acceptable to build a temporary of type pair from pair<U, V>, then move-assign from that temporary?

It sounds more like an issue waiting to be opened, unless you want to plug it now. As written we risk moving from lvalues.