This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4237. The standard library iterator adaptor does not handle iterator_category correctly

Section: 24.5.3.3 [const.iterators.iterator], 25.7 [range.adaptors] Status: New Submitter: Hewill Kang Opened: 2025-03-27 Last modified: 2025-03-29

Priority: Not Prioritized

View all issues with New status.

Discussion:

Currently, basic_const_iterator, and several range adaptors such as filter_view's iterators provide iterator_category only when the underlying iterator models forward_iterator, implying that they expect those iterators should have a valid iterator_category.

However, this is incorrect because being a forward_iterator does not necessarily mean it is a Cpp17InputIterator, it just means that it probably meets the syntactic requirements of Cpp17InputIterator.

Any iterator that specializes iterator_traits and provides only iterator_concept without iterator_category is not a Cpp17InputIterator, for example, common_iterator with a difference_type of integer-class type.

In this case, instantiating these iterator adaptors will result in a hard error because the iterator_category they expect does not exist. The following illustrates the problem (demo):

#include <iterator>
#include <ranges>

int main() {
  auto r = std::views::iota(0ULL)
         | std::views::take(5)
         | std::views::common;

  static_assert(std::ranges::forward_range<decltype(r)>);
  
  std::basic_const_iterator ci(r.begin()); // 'iterator_category': is not a member of 'std::iterator_traits'

  auto f = r | std::views::filter([](auto) { return true; });
  auto b = f.begin();                      // 'iterator_category': is not a member of 'std::iterator_traits'
}

I believe that checking if the underlying iterator is a forward_iterator is not an appropriate mechanism to provide iterator_category, but rather checking if its iterator_traits specialization provides iterator_category.

This issue is somewhat related to LWG 3763⁽ⁱ⁾, which is a further consideration after LWG 3749⁽ⁱ⁾ has been resolved.

Proposed resolution: