3863. Is input_iterator guaranteed to have iter_const_reference_t?

Section: 24.5.3.2 [const.iterators.alias] Status: New Submitter: Hewill Kang Opened: 2023-01-26 Last modified: 2023-02-06

Priority: 2

View all issues with New status.

Discussion:

In the C++20 iterator system, input_iterator is guaranteed to have a common reference, which reflects the indirectly_readable requires common_reference_t<iter_reference_t<I>&&, iter_value_t<I>&> to be a valid type.

However, for iter_const_reference_t which with a similar form:

template<indirectly_readable It>
  using iter_const_reference_t =
    common_reference_t<const iter_value_t<It>&&, iter_reference_t<It>>;

it is still theoretically possible to create an input_iterator that does not have a valid iter_const_reference_t, for example:

#include <iterator>

struct ref {
  ref(int&);
};

struct rref {
  rref(const int&);
  rref(const ref&);
};

struct I {
  using value_type = int;
  using difference_type = std::ptrdiff_t;

  ref operator*() const;
  I& operator++();
  I operator++(int);

  friend rref iter_move(const I&);
};

static_assert(std::input_iterator<I>); // pass
using CR = std::iter_const_reference_t<I>;  // error: no type named 'type' in 'struct std::common_reference<const int&&, ref>'

which causes basic_const_iterator<I> to produce a hard error internally when it is instantiated.

[2023-02-06; Reflector poll]

Set priority to 2 after reflector poll. Seems contrived, should probably constrain not give a hard error. The question of whether each range needs to have const reference to elems is important.

Proposed resolution: