"the last change" for ranges

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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.

Sounds like at least a reasonable solution.  The thing I like about it is that, in
addition to safety, it allows for the range to do fancy and arbitrary stuff under
the hood if necessary to allow for saving.  Also, while we're fine tuning input
ranges vs. forward ranges, I think the concept of iterables as a catch-all for
ranges, opApply, builtins, etc. needs to be introduced and fine tuned, too.  We've
shown on this NG previously that, while ranges are usually preferable for the
flexibility they offer, opApply does have its legitimate use cases.