### 300. list::merge() specification incomplete

**Section:** 24.3.10.5 [list.ops] **Status:** CD1
**Submitter:** John Pedretti **Opened:** 2001-01-23 **Last modified:** 2016-01-28 10:19:27 UTC

**Priority: **Not Prioritized

**View all other** issues in [list.ops].

**View all issues with** CD1 status.

**Discussion:**

The "Effects" clause for list::merge() (24.3.10.5 [list.ops], p23)
appears to be incomplete: it doesn't cover the case where the argument
list is identical to *this (i.e., this == &x). The requirement in the
note in p24 (below) is that x be empty after the merge which is surely
unintended in this case.

**Proposed resolution:**

In 24.3.10.5 [list.ops], replace paragraps 23-25 with:

23 Effects: if (&x == this) does nothing; otherwise, merges the two
sorted ranges [begin(), end()) and [x.begin(), x.end()). The result
is a range in which the elements will be sorted in non-decreasing
order according to the ordering defined by comp; that is, for every
iterator i in the range other than the first, the condition comp(*i,
*(i - 1)) will be false.

24 Notes: Stable: if (&x != this), then for equivalent elements in the
two original ranges, the elements from the original range [begin(),
end()) always precede the elements from the original range [x.begin(),
x.end()). If (&x != this) the range [x.begin(), x.end()) is empty
after the merge.

25 Complexity: At most size() + x.size() - 1 applications of comp if
(&x ! = this); otherwise, no applications of comp are performed. If
an exception is thrown other than by a comparison there are no
effects.

*[Copenhagen: The original proposed resolution did not fix all of
the problems in 24.3.10.5 [list.ops], p22-25. Three different
paragraphs (23, 24, 25) describe the effects of *`merge`.
Changing p23, without changing the other two, appears to introduce
contradictions. Additionally, "merges the argument list into the
list" is excessively vague.]

*[Post-Curaçao: Robert Klarer provided new wording.]*