Section: 27.2 [iterator.requirements] Status: NAD Submitter: Jeffrey Yasskin Opened: 2011-11-21 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [iterator.requirements].
View all issues with NAD status.
Many iterators guarantee that references and pointers returned from their methods will outlive the iterator itself. Other useful iterators can't guarantee this, leading to the rule in 27.2 [iterator.requirements] p9 that "Destruction of an iterator may invalidate pointers and references previously obtained from that iterator."Some algorithms can take advantage of long-lived references by returning them, while they can adapt to short-lived references by returning by value instead. However, there doesn't seem to be a way in the standard to distinguish between these two types of iterators. The ForwardIterator requirements come close by saying "If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object." (27.2.5 [forward.iterators] p6) However, there are some subtle ways to satisfy this rule and still return a short-lived reference, meaning algorithms can't be guaranteed that forward_iterator_tag will imply long-lived references. On the other hand, defect 198, which added the invalidation wording to iterator.requirements.general, refers to iterators with short-lived references being used as arguments to reverse_iterator, which requires BidirectionalIterators. If ForwardIterator required long-lived references, this would be impossible. Either ForwardIterator should be clarified to require long-lived references, or a new category should be added that does. See also the discussion around c++std-lib-31477. Daniel: Related to this issue is that when applying N3066 we unintentionally lost some forward iterator requirements from C++03, where we had the post-conditions a == X(a) of X(a), and u == a of any copy operation from a to u. This wording must be restored as well.
Move to NAD.
This issue affects only Input Iterators, as all other categories are required to return a native reference, and are not (currently) allowed to return proxies. The issue with Input Iterators is known, and has been present since the original standard. Any change in this regard would be an extension requiring a more substantial paper than treatment as a simple issue.