This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 24.3.2.3[iterator.traits]Status:CD1Submitter: Dave AbrahamsOpened: 2003-12-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.traits].
View all issues withCD1 status.
Discussion:
The standard places no restrictions at all on the reference typeof input, output, or forward iterators (for forward iterators itonly specifies that *x must be value_type& and doesn't mentionthe reference type). Bidirectional iterators' reference type isrestricted only by implication, since the base iterator'sreference type is used as the return type of reverse_iterator'soperator*, which must be T& in order to be a conforming forwarditerator.
Here's what I think we ought to be able to expect from an inputor forward iterator's reference type R, where a is an iteratorand V is its value_type
A mutable forward iterator ought to satisfy, for x of type V:
{ R r = *a; r = x; } is equivalent to *a = x;I think these requirements capture existing container iterators(including vector<bool>'s), but render istream_iterator invalid;its reference type would have to be changed to a constantreference.
(Jeremy Siek) During the discussion in Sydney, it was felt that asimpler long term solution for this was needed. The solution proposedwas to requirereference to be the same type as*aandpointer to be the same type asa->. Mostiterators in the Standard Library already meet this requirement. Someiterators are output iterators, and do not need to meet therequirement, and others are only specified through the generaliterator requirements (which will change with this resolution). Thesole case where there is an explicit definition of the reference typethat will need to change isistreambuf_iterator which returnscharT fromoperator* but has a reference type ofcharT&. We propose changing the reference type ofistreambuf_iterator tocharT.
The other option for resolving the issue withpointer, mentioned in the note below, is to removepointer altogether. I prefer placing requirements onpointer to removing it for two reasons. First,pointer will become useful for implementing iterator adaptors and in particular,reverse_iterator will become more well defined. Second, removingpointer is a rather drastic and publicly-visible action to take.
The proposed resolution technically enlarges the requirements foriterators, which means there are existing iterators (such asistreambuf_iterator, and potentially some programmer-definediterators) that will no longer meet the requirements. Will this breakexisting code? The scenario in which it would is if an algorithmimplementation (say in the Standard Library) is changed to rely oniterator_traits::reference, and then is used with one of theiterators that do not have an appropriately definediterator_traits::reference.
The proposed resolution makes one other subtle change. Previously,it was required that output iterators have adifference_typeandvalue_type ofvoid, which means that a forwarditerator could not be an output iterator. This is clearly a mistake,so I've changed the wording to say that those types may bevoid.
Proposed resolution:
In 24.3.2.3[iterator.traits], after:
be defined as the iterator's difference type, value type and iteratorcategory, respectively.
add
In addition, the types
iterator_traits<Iterator>::referenceiterator_traits<Iterator>::pointermust be defined as the iterator's reference and pointer types, thatis, the same type as the type of
*aanda->,respectively.
In 24.3.2.3[iterator.traits], change:
In the case of an output iterator, the types
iterator_traits<Iterator>::difference_typeiterator_traits<Iterator>::value_typeare both defined as
void.
to:
In the case of an output iterator, the types
iterator_traits<Iterator>::difference_typeiterator_traits<Iterator>::value_typeiterator_traits<Iterator>::referenceiterator_traits<Iterator>::pointermay be defined as
void.
In 24.6.4[istreambuf.iterator], change:
typename traits::off_type, charT*, charT&>
to:
typename traits::off_type, charT*, charT>
[Redmond: there was concern in Sydney that this might not be the only placewhere things were underspecified and needed to be changed. Jeremyreviewed iterators in the standard and confirmed that nothing elseneeded to be changed.]