@jwakely Sure, no good reason to introduce a separate i. I can change it.

I don't see how the implication is clear? It seems to say that distance will just return the number of necessary increments to get from point a to point b, not that it will necessarily perform them.

Let's say I make an iterator that has some side-effect like printing hello world every time it's incremented. And let's say it does not expose the interface of a random-access iterator, but the compiler and/or stdlib are able to figure out that it does in fact point into a random-access structure, and optimize away the increments to return the correct value from distance but avoid printing hello world.

Is that conforming? I think according to the standard as currently written, it is: the standard just says distance returns the number of increments required, not that it actually performs them. But I think according to the clear design intent, it wasn't meant to be.

But the standard doesn't say that magic, impossible optimisation happens, so you can't assume it does, and have to assume the increments happen, and so other copies of input iterators can be affected.

Saying "no impossible magic happens" doesn't seem necessary to me. A note stating that input iterators might become non-dereferenceable might be reasonable, but specifying the function using code isn't an improvement IMHO.

But the standard doesn't say that magic, impossible optimisation happens, so you can't assume it does

Right, but it also doesn't state that the increments do happen, as far as I can tell.

I'm not convinced the rewrite as code is a net improvement. I do sympathize with the sentiment that "needed to get" is sloppy wording of sorts; is there maybe a small prose adjustment that helps here? "increments first until last is reached and returns the number of increments" or so?

Editorial meeting: Go with Jens' suggestion.

Please be sure to keep the wording style consistent in std::advance, std::distance, ranges::advance, and ranges::distance.