Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 13:58:56

> 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.

> Maybe if your iterators are so peculiar and you want to be able to rely 
> on that property, you should use something else than iterator_range 
> which is designed for all iterators.

Or perhaps you could take the opposite view of saying: "I've never seen usage
like this, but that doesn't make it invalid.  Let's see if we can find a way of
making this work."  The biggest amount I've learn about programming was through
people who used my libraries in ways I couldn't even imagine.

Anyway, I think a lot of people on this forum are missing the point:  I'm not
claiming that the old behaviour is in some way better or worse.  
I am saying the following:  
1)  Is the behavioural change too much of a diversion from previous expected
(documented) functionality that the new change is in fact a defect
2)  There are clearly (at least two) distinct classes of problem and I think
they can both be solved.  We don't need to shove a square peg into a round hole
here.

Tom

Tom