"the last change" for ranges

[BLS]

Andrei Alexandrescu wrote:
> In wake of a few discussion I've witnessed, I'm thinking of a last 
> change for ranges. (In fact there's one more, but that's minor.)
> 
> The problem is that input ranges and forward ranges have the same 
> syntactic interface, but different semantic interfaces. Consider the 
> problem of finding the first two identical adjacent items in a range:
> 
> R adjacentFind(R)(R r)
> {
>     if (r,empty) return r;
>     R last = r;
>     r.popFront;
>     for (; !r.empty && last.front != r.front; last.popFront, r.popFront)
>     {
>     }
>     return r;
> }
> 
> This will work properly on lists and vectors, but horrendously on files 
> and sockets. This is because input ranges can't be saved for later use: 
> incrementing r also increments popFront and essentially forces both to 
> look at the same current value.
> 
> I'm thinking a better design is to require any range that's forward or 
> better to define a function save(). Ranges that don't implement it are 
> input ranges; those that do, will guarantee a brand new range is 
> returned from save(). So then adjacentFind would look like this:
> 
> R adjacentFind(R)(R r)
> {
>     if (r,empty) return r;
>     R last = r.save;
>     r.popFront;
>     for (; !r.empty && last.front != r.front; last.popFront, r.popFront)
>     {
>     }
>     return r;
> }
> 
> Obviously, when you pass a range that doesn't support save, adjacentFind 
> will not compile, which is what we want.
> 
> Andrei
> 
> P.S. There is a way to implement adjacentFind for forward ranges by 
> saving data instead of ranges. I've used a limited version above for 
> illustration purposes.

I REALLY hope that ranges will have some room  for a "Let's have a 
closer look" chapter in your book.  Sometimes I found them quite hard to 
understand:
Björn