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

### 296. Missing descriptions and requirements of pair operators

Section: 22.3 [pairs] Status: C++11 Submitter: Martin Sebor Opened: 2001-01-14 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [pairs].

View all issues with C++11 status.

Discussion:

The synopsis of the header `<utility>` in 22.2 [utility] lists the complete set of equality and relational operators for `pair` but the section describing the template and the operators only describes `operator==()` and `operator<()`, and it fails to mention any requirements on the template arguments. The remaining operators are not mentioned at all.

[ 2009-09-27 Alisdair reopens. ]

> The issue is a lack of wording specifying the semantics of `std::pair` relational operators. The rationale is that this is covered by catch-all wording in the relops component, and that as relops directly precedes `pair` in the document this is an easy connection to make.

> Reading the current working paper I make two observations:

> 1. relops no longer immediately precedes `pair` in the order of specification. However, even if it did, there is a lot of `pair` specification itself between the (apparently) unrelated relops and the relational operators for `pair`. (The catch-all still requires `operator==` and `operator<` to be specified explicitly)
> 2. No other library component relies on the catch-all clause. The following all explicitly document all six relational operators, usually in a manner that could have deferred to the relops clause.

> >     tuple
> >     unique_ptr
> >     duration
> >     time_point
> >     basic_string
> >     queue
> >     stack
> >     move_iterator
> >     reverse_iterator
> >     regex submatch
> >     thread::id

> The container components provide their own (equivalent) definition in 24.2.2.1 [container.requirements.general] Table 90 -- Container requirements and do so do not defer to relops.

> `Shared_ptr` explicitly documents `operator!=` and does not supply the other 3 missing operators (`>`,`>=`,`<=`) so does not meet the reqirements of the relops clause.

> `Weak_ptr` only supports `operator<` so would not be covered by relops.

> At the very least I would request a note pointing to the relops clause we rely on to provide this definition. If this route is taken, I would recommend reducing many of the above listed clauses to a similar note rather than providing redundant specification.

> My preference would be to supply the 4 missing specifications consistent with the rest of the library.

[ 2009-10-11 Daniel opens 1233 which deals with the same issue as it pertains to `unique_ptr`. ]

[ 2009-10 Santa Cruz: ]

> Move to Ready

Proposed resolution:

After p20 22.3 [pairs] add:

>     template <class T1, class T2>
>     bool operator!=(const pair<T1,T2>& x, const pair<T1,T2>& y);

> > Returns: `!(x==y)`

>     template <class T1, class T2>
>     bool operator> (const pair<T1,T2>& x, const pair<T1,T2>& y);

> > Returns: `y < x`

>     template <class T1, class T2>
>     bool operator>=(const pair<T1,T2>& x, const pair<T1,T2>& y);

> > Returns: `!(x < y)`

>     template <class T1, class T2>
>     bool operator<=(const pair<T1,T2>& x, const pair<T1,T2>& y);

> > Returns: `!(y < x)`

Rationale:

[operators] paragraph 10 already specifies the semantics. That paragraph says that, if declarations of operator!=, operator>, operator<=, and operator>= appear without definitions, they are defined as specified in [operators]. There should be no user confusion, since that paragraph happens to immediately precede the specification of `pair`.