Legal forward iterators cannot store their referents (was: counting_iterator::reference lifetime tied to iterator)

[schoedl]

The iterators library needs a redesign based on the facts noted in this comment

The original report is below.

---

Currently, counting_iterator<T>::reference is Incrementable const&. This makes reverse_iterator< counting_iterator<T> >::dereference return a reference to a temporary variable:

typename super_t::reference dereference() const { return *boost::prior(this->base()); }

The problem is that iterator::reference is expected to stay valid even if the iterator it was obtained from is dead.

[schoedl]

patch

[Dean Michael Berris]

I'm not sure I understand the consequences of this patch. Iterator references are meant to be valid only while the actual source of the data is still valid. This is the same reason why iterators typically don't own the data it refers to.

I don't see why the semantics should change for counting iterator. Unless there is really a bug with the implementation (i.e., a reproducible crash or relying on undefined behavior) then I don't see why this patch solves anything.

[Dave Abrahams]

The history of iterators that own the object they reference is somewhat complicated. counting_iterator does own its referent. To be a valid forward iterator, its reference type must be a true C++ reference. Otherwise, it would be limited to input iterator. Trying to accomodate forward iterators that store their referent caused innumerable contortions in the design of this library.

However, recent re-readings of the C++03 standard make it clear to me that such iterators are not allowed to be forward iterators anyway. In particular, below table 74 it says:

— If a and b are both dereferenceable, then a == b if and only if *a and *b are the same object.

So IMO, the library design needs to be revisited in terms of this new understanding. I don't want to address it piecemeal, because anything we do will break someone's code, and I want to make those changes all at once.