Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/7/10 8:24 CDT, Steven Schveighoffer wrote:
> On Wed, 06 Oct 2010 19:09:15 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 10/6/10 12:50 CDT, Steven Schveighoffer wrote:
>>> I agree all of this except for save() (not a secret to anyone who's read
>>> my posts).
>>
>> What was your alternative design that obviates save()?
>
> First, let me discuss why I don't like save.
>
> Let's classify ranges into two types. Primitive ranges are ones that
> provide a range interface to data that otherwise does not have a range
> interface. A good example is a container range.
>
> Compound ranges are ranges that combine or alter range functionality
> from a wrapped range or set of ranges. A good example is Zip or Chain.
>
> Let's also define the trivial save implementation as a single line:
> return this;
>
> We can assume that compound ranges don't contain a trivial solution, but
> only because the range(s) they contain could implement a non-trivial
> solution. So we can qualify those trivial, even though they don't have
> the canonical trival solution.
>
> Most ranges that are not compound implement the trivial solution. This
> includes all dcollections ranges and *ALL* non-compound ranges in phobos.
>
> Then there are ranges which cannot implement save whatsoever, even if
> they wanted to. A range that provides the range interface for a network
> stream would be a good example.
>
> That leaves us with ranges which cannot implement the trival solution,
> but can implement save. A class-based range would be a good example.
> Currently, there are zero examples of this type of range. That's right,
> zero (grep 'save()' std/*.d). I contend that we have no place for such
> ranges in D.
>
> So my question is, what is the point of save? The whole point is for
> this last class of ranges, so they can implement a way to copy the
> iteration position in a way that isn't doable via simple assignment. But
> there *AREN'T ANY* of these ranges in existence. Why do we have a
> feature that is littered all over phobos and any range that wants to be
> more than a basic imput range when the implementation is return this; ?
[snip]

I knew my retort for a while now, but neglected to write it down.

David Simcha added dynamic interfaces for std.range, in which save() 
does work and is actually instrumental. That suggests save() is useful. 
Now, dynamic interfaces are not just an obscure corner case, so I think 
they're here to stay and provide a compelling use case.


Andrei