Daniel Walker skrev:
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,
Is an iterator_range not a range? I don't recall anything like this. Was I the one that changed the test? -Thorsten