130. Return type of container::erase(iterator) differs for associative containers

Section: 26.2.6 [associative.reqmts], 26.2.3 [sequence.reqmts] Status: CD1 Submitter: Andrew Koenig Opened: 1999-03-02 Last modified: 2016-02-10

Priority: Not Prioritized

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with CD1 status.

Duplicate of: 451

Discussion:

Table 67 (23.1.1) says that container::erase(iterator) returns an iterator. Table 69 (23.1.2) says that in addition to this requirement, associative containers also say that container::erase(iterator) returns void. That's not an addition; it's a change to the requirements, which has the effect of making associative containers fail to meet the requirements for containers.

Proposed resolution:

In 26.2.6 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q) from void to iterator. Change the assertion/not/pre/post-condition from "erases the element pointed to by q" to "erases the element pointed to by q. Returns an iterator pointing to the element immediately following q prior to the element being erased. If no such element exists, a.end() is returned."

In 26.2.6 [associative.reqmts], in Table 69 Associative container requirements, change the return type of a.erase(q1, q2) from void to iterator. Change the assertion/not/pre/post-condition from "erases the elements in the range [q1, q2)" to "erases the elements in the range [q1, q2). Returns q2."

In 26.4.4 [map], in the map class synopsis; and in 26.4.5 [multimap], in the multimap class synopsis; and in 26.4.6 [set], in the set class synopsis; and in 26.4.7 [multiset], in the multiset class synopsis: change the signature of the first erase overload to

   iterator erase(iterator position);

and change the signature of the third erase overload to

  iterator erase(iterator first, iterator last); 

[Pre-Kona: reopened at the request of Howard Hinnant]

[Post-Kona: the LWG agrees the return type should be iterator, not void. (Alex Stepanov agrees too.) Matt provided wording.]

[ Sydney: the proposed wording went in the right direction, but it wasn't good enough. We want to return an iterator from the range form of erase as well as the single-iterator form. Also, the wording is slightly different from the wording we have for sequences; there's no good reason for having a difference. Matt provided new wording, (reflected above) which we will review at the next meeting. ]

[ Redmond: formally voted into WP. ]