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. In my opinion, the Range concept should not have 'singular'. I appreciate that there were previous discussions prior to your change, but under firther scrutiny it appears that the wrong conclusion was reached. On Tue, Nov 25, 2008 at 3:30 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Tomas Puverle skrev:
If the compromise does not include going back to the old behavior for
boost::iterator_range, then I'm open to suggestions
(Joke intended) This really doesn't seem to meet the criteria for a "compromise". Just sounds like you're getting your way.
Perhaps erroneous use of singular iterators could be added through improvements to iterator debugging facilities?
Why? I'm open to including a new class with the old behavior, even though I think it has little purpose.
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.
Wha compromise did you have in mind?
-Thorsten
Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost