JTC1/SC22/WG21 N3169

A Few Small Library Issues

SC22/WG21/N3169
Date: 2010-10-14
Author: P.J. Plauger

ISSUE 1. duration::operator* has template parameters in funny order.

In [time] and [time.duration.nonmember] we have:

template <class Rep1, class Period, class Rep2>
    duration<typename common_type<Rep1, Rep2>::type, Period>
        operator*(const Rep1& s, const duration<Rep2, Period>& d);

Everywhere else, we always have <rep, period> in that order for a given
type. But here, we have Period and Rep2 in reverse order for <Rep2, Period>.
This is probably of little importance, since the template parameters are
seldom spelled out for a function like this. But changing it now will
eliminate a potential source of future errors and confusion.

PROPOSAL:

Change the signature in [time] and [time.duration.nonmember] to:

template <class Rep1, class Rep2, class Period>
    duration<typename common_type<Rep1, Rep2>::type, Period>
        operator*(const Rep1& s, const duration<Rep2, Period>& d);

---
ISSUE 2. conj specification is now nonsense.

In Pittsburgh, we accepted the resolution of library issue 1137, to add
a sentence 3 to [cmplx.over]:

"All the specified overloads shall have a return type which is the nested
value_type of the effectively cast arguments."

This was already true for four of the six functions except conj and proj.
It is not completely unreasonable to make proj return the real value only,
but the IEC specification does call for an imaginary part of -0 in some
circumstances. The people who care about these distinctions really care,
and it *is* required by an international standard.

Making conj return just the real part breaks it horribly, however. It is
well understood in mathematics that conj(re + i*im) is (re - i*im), and it
is widely used. The accepted new definition makes conj useful only for
pure real operations. This botch *absolutely must* be fixed.

PROPOSAL:

Remove the recently added sentence 3 from [cmplx.over].

---
ISSUE 3. unordered_map::insert(T&&) protection should apply to map too.

In [unord.map.modifiers], the signature:

template <class P>
    pair<iterator, bool> insert(P&& obj);

now has an added Remarks paragraph:

Remarks: This signature shall not participate in overload resolution
unless P is implicitly convertible to value_type.

The same is true for unordered_multimap.

But neither map nor multimap have this constraint, even though it is a
Good Thing(TM) in those cases as well.

PROPOSAL:

Add the same Remarks clause to [map.modifiers] and [multimap.modifiers].