Do the Range TS and C++20 concepts for iterators require the ability to use `operator->`?

Question

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.

Since 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 -> support.

Is this the case?

Answer 1

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:

1. There's no way to implement -> for many iterator types such that the semantics of i->m are equivalent to (*i).m as the "old" requirements expect. move_iterator is a good example: (*i).m is an rvalue, whereas i->m is an lvalue. (Yes, it's yet another Standard iterator that doesn't satisfy the iterator requirements.)
2. 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.
3. 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.