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.
Section: 24.5.1.6 [reverse.iter.elem] Status: CD1 Submitter: Matt Austern Opened: 2002-10-23 Last modified: 2021-06-06
Priority: Not Prioritized
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(i), 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 24.5.1.3 [reverse.iter.requirements] change:
reference operator[](difference_type n) const;
to:
unspecified operator[](difference_type n) const; // see 24.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. ]