On Tue, Nov 25, 2008 at 4:43 PM, David Abrahams <dave@boostpro.com> wrote:
Sent from my iPhone
On Nov 25, 2008, at 10:40 AM, "Neil Groves" <neil@grovescomputing.com> 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