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 23:25:52

First off, Tom, please cite who you're quoting. It makes the
discussion difficult to follow when you respond to quotes that aren't
attributed to anyone. Please follow the discussion guidelines at
http://www.boost.org/community/policy.html, in particular the section
"Use a Readable Quotation Style."

On Sat, Nov 22, 2008 at 9:45 PM, Tomas Puverle
<Tomas.Puverle_at_[hidden]> wrote:
>> Sure there are, but that's irrelevant. The standard doesn't require
>> iterators that have been constructed to be in a valid state, and that's
>> all there is to it.
>
> By the same logic, we should never be able to build any compound types which
> have any members which could potentially be in some invalid state.

The point is that iterators are default constructible and may
therefore exist in an invalid state. The probable of maintaining the
validity of an iterator, or a pointer, is tricky. Actually, this is
one of the motivations for ranges; they help maintain the validity of
iterators by organizing them in pairs that define the boundaries of a
traversable range. The Range concept documentation has always stated
that a valid range x is one where boost::end(x) is reachable from
boost::begin(x). In your use case, as far as I understand, you do not
necessarily have a valid range.

<snip>
> I gave a demonstrable use case, which, IMHO, is actually very powerful thanks to
> the generality of iterator_range.  Not one of the opponents of what we're saying
> has come up with a single suggestion of how the current iterator_range can meet
> my needs or justify why it should be acceptable for boost to change documented
> behaviour without any notice.

As for undocumented changes, that's unjustifiable. (I'm also
aggravated about the changes to the Range concepts, and I wish I had
been paying closer attention, 'cause I would have protested.)

As for your needs, we're trying to help, if you're willing to listen.
I disagree with you that iterator_range is a particularly generic
solution. I would suggest writing for the Range concepts in general.
As for the actual implementation of a range, I much prefer std::pair,
and I would recommend that you use it. If you're code was written
specifically for iterator_range, you'll have some searching and
replacing and sed and awking ;) and possibly other refactoring to do.
If you're code was written generically for any Range, then the
transition from iterator_range to std::pair should be trivial and
painless. That's one of the points of generic programming: Don't be
bound to a particular class or type, be free! :)

I'm sorry for any discrepancies between iterator_range documentation
and the Range concept documentation and the actual iterator_range
implementation in any given release. Apparently, there were changes
that probably should not have been made. However, it sounds to me like
you want to create invalid ranges. So in that respect, Boost.Range is
not broken, your use case is.

Now, interestingly, one might ask for a new feature - a function to
test if a range is valid. But since range validity is defined in terms
of one iterator being reachable from another, range validity testing
is actually an instance of the halting problem! So, I guess we can't
really implement that one. ;)

Anyway, I'm not sure how to untie this knot. I guess we need Thorsten's input.

Daniel Walker