Proposed resolution:

Add a paragraph to [pairs]:

template<class U, class V> pair(U&& x, V&& y);

6 Effects: The constructor initializes first with std::forward<U>(x) and second with std::forward<V>(y).

Remarks: U shall be implicitly convertible to first_type and V shall be implicitly convertible to second_type, else this constructor shall not participate in overload resolution.

[ The rationale is obsolete. ]

[ San Francisco: ]

Solved by N2770.

[ 2010-02-09 Moved to Tentatively Ready after 6 positive votes on c++std-lib. ]

[ 2010-02-06 Howard provided wording. ]

[ 2009-10 Santa Cruz: ]

Leave as open. Howard to provide wording.

[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]

[ San Francisco: ]

Suggested to resolve using pass-by-value for that case.

Side question: Should pair interoperate with tuples? Can construct a tuple of a pair, but not a pair from a two-element tuple.

Related to 885.

#include <utility>

int main()
{
   std::pair<char *, char *> p (0,0);
}

I just got a bug report about that, because it's valid C++03, but not C++0x. The important realization, for me, is that the emplace proposal---which made push_back variadic, causing the push_back(0) issue---didn't cause this break in backward compatibility. The break actually happened when we added this pair constructor as part of adding rvalue references into the language, long before variadic templates or emplace came along:

template<class U, class V> pair(U&& x, V&& y);

Now, concepts will address this issue by constraining that pair constructor to only U's and V's that can properly construct "first" and "second", e.g. (from N2322):

template<class U , class V >
requires Constructible<T1, U&&> && Constructible<T2, V&&>
pair(U&& x , V&& y );