Please cite who you're quoting. See the discussion policy at http://www.boost.org/community/policy.html. On Sat, Nov 22, 2008 at 1:58 PM, Tomas Puverle <Tomas.Puverle@morganstanley.com> wrote:
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.
I was about to suggest that if you want to build a generic library that uses ranges, stick to the Range concepts (http://tinyurl.com/5z56n2) and avoid tying yourself to types generated from iterator_range. Tight bundling always causes problems like this. With concepts all of the constraints on a type can be encoded in a concept checking class and automatically verified at compile time (and of course proposed C++0x language extensions could make this even easer/cleaner). Users can rely on the concepts being implemented, and authors can use concept checks to make sure their implementations meet user expectations. Unfortunately, the Range concept checks appear to have been changed about a year ago, apparently in response to the changes in iterator_range. As far as I can tell from looking at the svn history, when iterator_range failed to meet the Range concepts, rather than changing iterator_range, the concept checks were gutted. If you don't pass the test, change the test?!!! :( This entirely defeats the purpose of concepts, which obviously are meant to be independent of particular types, and is contrary to the entire paradigm of generic programming. So, though I wish I could, I can't suggest that you use Range concepts rather than iterator_range, because both were changed without being properly announced or vetted. That's frustrating. Perhaps a procedural solution that could avert this problem in the future is to quarantine the test cases. Authors can maintain commit privileges to their libraries on trunk, but only a select group of independent guardians have commit privileges to the test cases. That way there is a guarantee that libraries pass the same tests from one release to another. If an author would like to make a change that would break a test case, he or she would need to present the change to the list and submit a patch to the test case sentinels. This would be a fairly simple quality assurance protocol: engineers aren't allowed to do their own QA. Daniel Walker