Rationale:

Discussed in Santa Cruz. An overwhelming majority of the LWG believes this should not be treated a DR: it's a request for a design change, not a defect in the existing standard. Most people (10-3) believed that we probably don't want this change, period: as with issue 348, it's hard to know where to draw the line. The LWG noted that users who want to put objects into an associative container for which operator< isn't defined can simply provide their own comparison function object.

Proposed resolution:

Informally: Add a specialization of std::less for std::complex.

[ Bellevue: ]

This is a request for a design change, and not a defect in the standard. It is in scope to consider, but the group feels that it is not a change that we need to do. Is there a total ordering for floating point values, including NaN? There is not a clear enough solution or big enough problem for us to solve. Solving this problem would require solving the problem for floating point, which is equally unclear. The LWG noted that users who want to put objects into an associative container for which operator< isn't defined can simply provide their own comparison function object. NAD

[ Pre Bellevue: Reopened at the request of Alisdair. ]

Practice with std::complex<> and the associative containers occasionally reveals artificial and distracting issues with constructs resembling: std::set<std::complex<double> > s;

The main reason for the above to fail is the absence of an appropriate definition for std::less<std::complex<T> >. That in turn comes from the definition of the primary template std::less<> in terms of operator<.

The usual argument goes as follows: Since there is no ordering over the complex field compatible with field operations it makes little sense to define a function operator< operating on the datatype std::complex<T>. That is fine. However, that reasoning does not carry over to std::less<T> which is used, among other things, by associative containers as an ordering useful to meet complexity requirements.

Related issue: 348.