https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
Bug ID: 100479 Summary: range adaptors handle cached iterators incorrectly Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- template<forward_range _Range> struct _CachedPosition<_Range> { private: iterator_t<_Range> _M_iter{}; public: constexpr bool _M_has_value() const { return _M_iter != iterator_t<_Range>{}; } constexpr iterator_t<_Range> _M_get(const _Range&) const { __glibcxx_assert(_M_has_value()); return _M_iter; } constexpr void _M_set(const _Range&, const iterator_t<_Range>& __it) { __glibcxx_assert(!_M_has_value()); _M_iter = __it; } }; - The domain of == for forward iterators is limited to iterators over the same underlying sequence. While value-initialized forward iterators of the same type may be compared against each other, comparing them against iterators into other ranges is not required to be well-defined, so it cannot be used as a sentinel value. - The cache cannot be allowed to propagate when the view containing it is copied/moved, and has to be invalidated when the view containing it is moved. Any cached iterator points to the original underlying view, and not the new one; also, moving from a view can change its value (if it is well-defined to use the moved-from view), so the cache is no longer valid. (Handling this case correctly was actually the original use case for non-propagating-cache in range-v3.)