I think this is the right answer (and pretty well argued by now). The
behavior of the iterator_range should "inherit" (is there a better word for this?) its semantics from the underlying iterator. To do otherwise would impose requirements on iterators that may not (easily) support those semantics, making the concept less generic (as in represents fewer possible implementations).
Well, it is fairly easy to remove some of the debug-checks from the code. Do I understand you correctly in that you want them all removed?
No! Definitely no. As I understand it, those debug checks are kind of playing the role of axiomatic preconditions in debug mode, so they're actually reinforcing the correct behavior. I think. I think from a previous post I was considering a kind of checked iterator_range that could provide additional diagnostics in debug mode - something akin to the STLPort checked iterators. Providing something like that as a compile-time replacement for iterator_range would free that class up to be as lean as possible and sans preprocessor. Completely outside the scope of the discussion... sorry. Andrew Sutton andrew.n.sutton@gmail.com