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

### 386. Reverse iterator's operator[] has impossible return type

Section: 25.5.1.6 [reverse.iter.elem] Status: CD1 Submitter: Matt Austern Opened: 2002-10-23 Last modified: 2021-06-06

Priority: Not Prioritized

View other active issues in [reverse.iter.elem].

View all other issues in [reverse.iter.elem].

View all issues with CD1 status.

Discussion:

In [reverse.iter.op-=], `reverse_iterator<>::operator[]` is specified as having a return type of `reverse_iterator::reference`, which is the same as `iterator_traits<Iterator>::reference`. (Where `Iterator` is the underlying iterator type.)

The trouble is that `Iterator`'s own operator[] doesn't necessarily have a return type of `iterator_traits<Iterator>::reference`. Its return type is merely required to be convertible to `Iterator`'s value type. The return type specified for reverse_iterator's operator[] would thus appear to be impossible.

With the resolution of issue 299, the type of `a[n]` will continue to be required (for random access iterators) to be convertible to the value type, and also `a[n] = t` will be a valid expression. Implementations of `reverse_iterator` will likely need to return a proxy from `operator[]` to meet these requirements. As mentioned in the comment from Dave Abrahams, the simplest way to specify that `reverse_iterator` meet this requirement to just mandate it and leave the return type of `operator[]` unspecified.

Proposed resolution:

In 25.5.1.3 [reverse.iter.requirements] change:

>     reference operator[](difference_type n) const;

to:

>     unspecified operator[](difference_type n) const; // see 25.3.5.7 [random.access.iterators]

[ Comments from Dave Abrahams: IMO we should resolve 386 by just saying that the return type of reverse_iterator's operator[] is unspecified, allowing the random access iterator requirements to impose an appropriate return type. If we accept 299's proposed resolution (and I think we should), the return type will be readable and writable, which is about as good as we can do. ]