"the last change" for ranges

[Denis Koroskin]

On Wed, 20 May 2009 20:19:30 +0400, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> 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.

Why not r.dup?