Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue4237 below:

The standard library iterator adaptor does not handle iterator_category correctly

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.

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

Priority: 3

View other active issues in [const.iterators.iterator].

View all other issues in [const.iterators.iterator].

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.

[2025-06-12; Reflector poll]

Set priority to 3 after reflector poll.

Proposed resolution:

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4