"the last change" for ranges

[Denis Koroskin]

On Wed, 20 May 2009 20:23:27 +0400, Denis Koroskin <2korden at gmail.com> wrote:

> 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?

Nevermind, I don't want to turn it into a bycicle shed discussion, but .dup would be consistent with arrays.

Do you suggest that ranges now have a reference semantics? That's quite a big change, but I do believe that it's for good, because it make classes a rightful ranges citizen.