Shout out to D at cppcon, when talkign about ranges.

[Walter Bright via Digitalmars-d]

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?