Proposed resolution:

Change [deque.modifiers], p4:

iterator erase(const_iterator position); 
iterator erase(const_iterator first, const_iterator last);

-4- Effects: An erase in the middle of the deque invalidates all the iterators and references to elements of the deque and the past-the-end iterator. An erase at either end of the deque invalidates only the iterators and the references to the erased elements, except that erasing at the end also invalidates the past-the-end iterator.

[ Bellevue: ]

Note that there is existing code that relies on iterators not being invalidated, but there are also existing implementations that do invalidate iterators. Thus, such code is not portable in any case. There is a pop_front() note, which should possibly be a separate issue. Mike Spertus to evaluate and, if need be, file an issue.

[ Kona (2007): Proposed wording added and moved to Review. ]

[ Post Kona, Steve LoBasso notes: ]

My only issue with the proposed resolution is that it might not be clear that pop_front() [where size() == 1] can invalidate past-the-end iterators.

The standard states at [deque.modifiers]/4:

deque erase(...)

Effects: ... An erase at either end of the deque invalidates only the iterators and the references to the erased elements.

This does not state that iterators to end will be invalidated. It needs to be amended in such a way as to account for end invalidation.

Something like:

Any time the last element is erased, iterators to end are invalidated.

This would handle situations like:

erase(begin(), end())
erase(end() - 1)
pop_back()
resize(n, ...) where n < size()
pop_front() with size() == 1