However, that is certainly not guaranteed by the iterator concepts. Therefore, when you deal with iterators in a generic way, you should not assume such a thing.
And we're not.
iterator_range being a generic tool, it wants to maintain the invariants which are necessary to make it work whatever its parameters are, even if those invariants happen not to be necessary for some parameters.
But as a "generic" tool, iterator_range is now assuming too much and breaking existing code. Also, currently iterator_range is close to me wanting to say that it doesn't really maintain any invariants, IMHO.
Maybe if your iterators are so peculiar and you want to be able to rely on that property, you should use something else than iterator_range which is designed for all iterators.
Or perhaps you could take the opposite view of saying: "I've never seen usage like this, but that doesn't make it invalid. Let's see if we can find a way of making this work." The biggest amount I've learn about programming was through people who used my libraries in ways I couldn't even imagine. Anyway, I think a lot of people on this forum are missing the point: I'm not claiming that the old behaviour is in some way better or worse. I am saying the following: 1) Is the behavioural change too much of a diversion from previous expected (documented) functionality that the new change is in fact a defect 2) There are clearly (at least two) distinct classes of problem and I think they can both be solved. We don't need to shove a square peg into a round hole here. Tom Tom