This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 279. const and non-const iterators should have equivalent typedefs

Section: 22.2 [container.requirements] Status: NAD Submitter: Steve Cleary Opened: 2000-11-27 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [container.requirements].

View all issues with NAD status.

Discussion:

This came from an email from Steve Cleary to Fergus in reference to issue 179. The library working group briefly discussed this in Toronto and believes it should be a separate issue.

Steve said: "We may want to state that the const/non-const iterators must have the same difference type, size_type, and category."

(Comment from Judy) I'm not sure if the above sentence should be true for all const and non-const iterators in a particular container, or if it means the container's iterator can't be compared with the container's const_iterator unless the above it true. I suspect the former.

Proposed resolution:

In Section: 22.2 [container.requirements], table 65, in the assertion/note pre/post condition for X::const_iterator, add the following:

> typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)

> typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)

> typeid(X::const_iterator::category) == typeid(X::iterator::category)

Rationale:

Going through the types one by one: Iterators don't have a `size_type`. We already know that the difference types are identical, because the container requirements already say that the difference types of both X::iterator and X::const_iterator are both X::difference_type. The standard does not require that X::iterator and X::const_iterator have the same iterator category, but the LWG does not see this as a defect: it's possible to imagine cases in which it would be useful for the categories to be different.

It may be desirable to require X::iterator and X::const_iterator to have the same value type, but that is a new issue. (Issue 322.)