Proposed resolution:

1. Change Table 93 — Container requirements in [container.requirements.general] as indicated:

   Table 93 — Container requirements

   Expression	Return type	Operational semantics	Assertion/note pre-/post-condition	Complexity
   ...
   X::iterator	iterator type whose value type is T		any iterator category except output iterator that meets the forward iterator requirements. convertible to X::const_iterator	compile time
   X::const_iterator	constant iterator type whose value type is T		any iterator category except output iterator that meets the forward iterator requirements.	compile time
   ...

[ Adopted at 2010-11 Batavia ]

[ Post-Rapperswil: ]

Daniel notes: I changed the currently suggested P/R slightly, because it is not robust in regard to new fundamental iterator catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward iterator requirements.

Moved to Tentatively Ready with revised wording after 5 positive votes on c++std-lib.

The requirements on container iterators are spelled out in [container.requirements.general], table 91.

Table 91 — Container requirements

Expression	Return type	Operational semantics	Assertion/note pre-/post-condition	Complexity
...
X::iterator	iterator type whose value type is T		any iterator category except output iterator. Convertible to X::const_iterator.	compile time
X::const_iterator	constant iterator type whose value type is T		any iterator category except output iterator	compile time
...

As input iterators do not have the multi-pass guarantee, they are not suitable for iterating over a container. For example, taking two calls to begin(), incrementing either iterator might invalidate the other. While data structures might be imagined where this behaviour produces interesting and useful results, it is very unlikely to meet the full set of requirements for a standard container.