I've searched through various Range TS proposals, including P0896, the one incorporating the ranges into C++20. It seems from my reading that the only requirement the
Iterator concept makes in terms of dereferenceability is that
*t be valid syntax that yields an object of some type.
InputIterator is defined in terms of being an
Iterator and being
Readable, neither of which requires
operator-> support, it appears that the Range TS and C++20 do not require that iterators provide
Is this the case?
Yes, we've dropped the
operator-> requirement from
InputIterator, and consequently the iterator concepts that refine it. (The requirement remains part of the "old" input iterator requirements, which are unchanged.) There are a number of reasons:
- There's no way to implement
->for many iterator types such that the semantics of
i->mare equivalent to
(*i).mas the "old" requirements expect.
move_iteratoris a good example:
(*i).mis an rvalue, whereas
i->mis an lvalue. (Yes, it's yet another Standard iterator that doesn't satisfy the iterator requirements.)
- There's no way to usefully constrain
->with concepts. Sure, we could require that there is an
operator->, but we couldn't constrain it to have reasonable syntax.
- Most importantly,
->is useless to the standard algorithms: they have no idea if the elements denoted by an iterator have members, let alone how to name such members.
This doesn't mean that standard iterators won't provide
operator-> (Although see LWG 2790), only that iterators aren't required to implement such an operator to be usable with the standard library.