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: 25.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: