------- Additional Comments From atavory at gmail dot com 2005-09-26 22:22 ------- (In reply to comments #2 and #3: Actually, on second thought, I'm not sure we should give up consistency so easily only because the it = t.erase(it) idiom cannot be meaningfully used together with unordered containers: otherwise, why, f.i., vector::erase returns an iterator?!?!)
For hash-based containers, i = t.erase(i) is effectively similar to: t.erase(i->first) // or t.erase(*i) i = t.begin(); std::advance(i, ::rand() % t.size()); (In fact, it's even somewhat worse than the above.) How could the return value be useful? Conversely, i = t.erase(i) makes sense for both tree-based containers or vectors, as it can be used in snippets such as the one in the original post. The problem is not, IMHO, whether the container is ordered or not (e.g., an unsorted std::vector). The problem is whether the container's sequence is well defined. Prior to hash-tables, the STL had only containers with well-defined sequences. (Put differently, one can think of a vector (or even a list) as an "associative container" mapping 1 .. t.size() - 1 to the values of t.) So, IMHO, this isn't giving up consistency; it's just reflecting inherent inconsistency through an inconsistent interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
