David Abraham wrote: <big snip - cos I can't be bothered with this thread any more>
Okay, but should they both be in Boost, now that the damage is done? I'm not sure that's the right answer either. And, by the way, I'm not saying it's the wrong answer; I'm saying I haven't been convinced in either direction.
If Tom isn't prepared to accept using boost::old_iterator_range instead of boost::iterator_range, we have to break a bunch of other peoples' code, which seems worse to me. Then both groups of users will have been disrupted. If Tom *is* prepared to use boost::old_iterator_range, IMO it may as well be tom::iterator_range: we don't have to have this component in Boost at all, except as an example along with the change notes that tell you how to write a component with the old behavior if you need it.
It is absolutely clear from this post that you are missing the entire point. I've tried to cover the point from about 3 different directions, and each time you get bogged down in something off-topic. I'll give up, and in the process give up on using boost.range. It's rather pointless to use a library where you can have no confidence in functionality changing underneath you, and principles being different to the documentation. Dave