Etienne and Andrew thanks for your comments, please find my answers below...

On Tue, Feb 21, 2012 at 5:00 PM, Andrew Holden <> wrote:
Please don't top-post.  I've taken the liberty of moving your reply to the bottom where it belongs.

On Tuesday, February 21, 2012 10:33 AM, Etienne Pretorius wrote:
> On 21 Feb 2012, at 5:29 PM, Ovanes Markarian wrote:
> Hello Joaquín,
> the doc states in erase that an iterator or end-iterator is returned when erasing an
> element. What was the rationale behind returning the iterator? Where other members
> return the number of elements being removed.
> My point is that end-iterator is also returned when erasing an element where iterator
> points one before the end iterator. Now to be sure that  the specified element was
> really removed my call must either use the key and search for that element again or
> compare the size before and after the erase call.
> Probably so that you may selectively erase elements within a loop based on some criteria.

I can think of three reasons for this behavior:

1: multi_index mimics the behavior of STL containers to the greatest extent possible, and their erase(iterator) functions return the iterator of the following element.
Which ones? std::map<...>::erase either returns void or number of deleted elements.

2: Returning the iterator allows programs to easily erase elements without losing their place in the container.
Yes this is a good point, it might be possible to return a pair type containing the iterator and bool value.

3: The erase function is guaranteed to succeed.
What happens if some sw part mixes up the iterator from the other container instance? This might really be a clear case for assert, if the iterator and container know about each other...