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@morganstanley.com> 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