On 10/5/2015 9:39 AM, Eric Niebler wrote:
On Friday, 2 October 2015 at 22:57:52 UTC, Walter Bright wrote:
The begin and end are iterators, and don't encapsulate (i.e. constrain) what
can be done with those iterators. For example, begin can return an iterator
that can be used to increment right on past the end. The iterator itself has
no knowledge of where the end is.
For a D range, what happens if you popFront from an empty range? An assertion,
I'm guessing.
You'd be right, and this is easy to do because a range encapsulates this
knowledge.
It is not hard for a C++ iterator to do the same, and many debug
standard libraries have iterators that do that.
This is the issue that D ranges (and Matthew's and your's) solve. I believe
the difference is fundamental.
A C++ iterator can store a pointer back to its range and implement all its core
functionality in terms of simple operations like current, next, and done. The
Boost.Iterators and Boost.Range libraries made that possible and have been
around a long time.
Some iterators can be implemented more efficiently without an indirection to the
range. Those iterators are unsafe in the way you describe.
Yes, you can build debug iterators that know their limits, or iterators with
back pointers to the range. This is not an inherent property of Boost ranges,
does not appear in the Boost description of ranges (unless I missed it), and is
a kludge. I do not agree that D ranges owe anything to that design.
In fact, it looks like an attempt to make iterators themselves ranges, rendering
the Boost:range rather pointless?
