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.
Section: 26.7.9 [alg.unique] Status: CD1 Submitter: Angelika Langer Opened: 2000-05-15 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [alg.unique].
View all issues with CD1 status.
Discussion:
Some popular implementations of unique_copy() create temporary copies of values in the input sequence, at least if the input iterator is a pointer. Such an implementation is built on the assumption that the value type is CopyConstructible and Assignable.
It is common practice in the standard that algorithms explicitly specify any additional requirements that they impose on any of the types used by the algorithm. An example of an algorithm that creates temporary copies and correctly specifies the additional requirements is accumulate(), 29.5.3 [rand.req].
Since the specifications of unique() and unique_copy() do not require CopyConstructible and Assignable of the InputIterator's value type the above mentioned implementations are not standard-compliant. I cannot judge whether this is a defect in the standard or a defect in the implementations.
Proposed resolution:
In 25.2.8 change:
-4- Requires: The ranges [first, last) and [result, result+(last-first)) shall not overlap.
to:
-4- Requires: The ranges [first, last) and [result, result+(last-first)) shall not overlap. The expression *result = *first must be valid. If neither InputIterator nor OutputIterator meets the requirements of forward iterator then the value type of InputIterator must be copy constructible. Otherwise copy constructible is not required.
[Redmond: the original proposed resolution didn't impose an
explicit requirement that the iterator's value type must be copy
constructible, on the grounds that an input iterator's value type must
always be copy constructible. Not everyone in the LWG thought that
this requirement was clear from table 72. It has been suggested that
it might be possible to implement unique_copy without
requiring assignability, although current implementations do impose
that requirement. Howard provided new wording.]
[ Curaçao: The LWG changed the PR editorially to specify "neither...nor...meet..." as clearer than "both...and...do not meet...". Change believed to be so minor as not to require re-review. ]