This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

### 265. std::pair::pair() effects overly restrictive

Section: 22.3 [pairs] Status: CD1 Submitter: Martin Sebor Opened: 2000-09-11 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [pairs].

View all issues with CD1 status.

Discussion:

I don't see any requirements on the types of the elements of the std::pair container in 20.2.2. From the descriptions of the member functions it appears that they must at least satisfy the requirements of 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in the case of the [in]equality operators also the requirements of 20.1.1 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].

I believe that the the CopyConstructible requirement is unnecessary in the case of 20.2.2, p2.

Proposed resolution:

Change the Effects clause in 20.2.2, p2 from

> -2- Effects: Initializes its members as if implemented: `pair() : first(T1()), second(T2()) {}`

to

> -2- Effects: Initializes its members as if implemented: `pair() : first(), second() {}`

Rationale:

The existing specification of pair's constructor appears to be a historical artifact: there was concern that pair's members be properly zero-initialized when they are built-in types. At one time there was uncertainty about whether they would be zero-initialized if the default constructor was written the obvious way. This has been clarified by core issue 178, and there is no longer any doubt that the straightforward implementation is correct.