On Sat, Nov 22, 2008 at 09:13, Andrey Semashev <andrey.semashev@gmail.com> wrote:
With such a notion this, indeed, is a rather useless component. I have to agree with Tomas and others in one of their points: one of the major advantages or ranges before pairs of iterators is that they attempt to reproduce containers as far as possible. 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.
I think you just raised the most important point in this thread. iterator_range<ostream_iterator<string> >() is not singular, yet 1.37 will say it is, so that's clearly wrong. But yet, the old way is also bad. iterator_range<string::iterator>() was singular, with its empty() returning true, while the conceptually equilavent iterator_range<string::iterator>(string::iterator(), string::iterator()), which is also singular, has an empty() that invokes UB. Also, what if I write a random_number_iterator, a forward iterator which returns a different random number after each increment? Then iterator_range<random_number_iterator>() is again non-singular, and it has an infinite size (operator== would always be false), so the empty() for the range should *not* return false. An iterator_range is just that, and trying to hide what it is seems doomed to failure.
The documentation of the iterator_range states for several functions, such as size() and operator[], that these functions depend on the iterator nature. I believe, empty() could just do the same - rely on the ability to compare iterators, even default-initialized ones. Of course, this should be clearly stated in the docs.
That is, as mentioned, precisely what has been stated in the docs since at least 1_33_1.