Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Neil Groves (neil_at_[hidden])
Date: 2008-11-25 11:50:39

On Tue, Nov 25, 2008 at 4:43 PM, David Abrahams <dave_at_[hidden]> wrote:

>
>
> Sent from my iPhone
>
> On Nov 25, 2008, at 10:40 AM, "Neil Groves" <neil_at_[hidden]>
> wrote:
>
>  Thorsten,
>>
>> I think the majority of opinions on this thread have voiced a preference
>> for
>> the old behaviour because singularity is a property of an iterator, not a
>> range. Adding the validity constraint imposes too many restrictions upon
>> otherwise valid uses of default constructed iterator_ranges where the
>> iterator provides stronger guarantees.
>>
>
> You don't need the old behavior (which attempted to provide those
> guarantees even when the underlying iterators can't, at the cost of space
> and time) to have that.
>
>
>> In my opinion, the Range concept should not have 'singular'.
>>
>
> Protecting users from singular iterators at the cost of space and time,
> especially in those cases when the iteratirs themselves already provide a
> nonsingular default-constructed state, of a bad idea.
>

I absolutely agree even though my original post may appear to indicate
otherwise. I am in agreement that we simply shouldn't be checking for
singularity at the range level. It appears that I may have misunderstood the
old behaviour due to my failure to browse the old versions of the code. The
whole singularity 'thing' should be dropped from ranges.

In summary I think that there should be one class iterator_range without the
checking.

<snip>

>
>> I don't think two classes that are almost identical is worthwhile. The
>> singularity validation does not serve enough useful purpose to justify the
>> limitations, and space overhead. Singularity debugging does not belong
>> here.
>>
> </snip>

Neil Groves