Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-11-22 15:42:25

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_at_[hidden]> 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