Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-11-22 14:50:21

On Sat, Nov 22, 2008 at 8:13 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

> Andrey Semashev wrote:
>
>  Yes, in general default-constructed
>> iterators are singular and they cannot be used reliably. However, not all
>> iterators behave that way. Pointers, for example, are NULL on
>> default-initialization (which is used in the default constructor of the
>> iterator_range class). I can well have my own iterators that are
>> default-constructible and allow comparison in this state. And I don't
>> understand why an iterator range of these iterators suddenly restricts me
>> from being able to compare these iterators in empty(), for example.
>>
>
>
> Iterators where default-construction leads to a valid past-the-end iterator
> for all sequences are a fairly special case of iterators, even if they
> happen to be quite common.
> 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.
>
> 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.
>

I think this is the case when excessive invariant checking does more harm
than good. I hate to reiterate, but I think it should be up to user whether
to rely on the ability to compare default-constructed iterators or not. The
library, being as you rightfully say, a generic tool, must not impose
excessive restrictions on the use model of the underlying iterators. Right
now the library does so, which basically cancels a considerable set of valid
use cases. I would say, it contradicts the term "a generic tool".

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.

I'll probably do so in the future. But I must say I don't see the advantage
of iterator ranges in light of this statement. I think such major changes in
the library philosophy, that affect the overall library value, should result
in a separate review (maybe a fast-track one) before committing.