"the last change" for ranges

[Robert Jacques]

On Wed, 20 May 2009 13:04:42 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>> On Wed, May 20, 2009 at 9:19 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> 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.
>>  The only other alternative that comes to mind would be forcing input
>> ranges to hide their copy constructor, or whatever the D equivalent
>> is, making R last = r; fail.  But that would make input ranges very
>> difficult to use.
>
> Exactly. I thought of that design, and it was difficult to even pass a  
> range to a function.
>
>> So, of those two options at least, requiring a .save sounds like the
>> better choice.
>>  The down side is you will get no error if you write the code the first
>> way, without a .save.   I see this as turning into tip #5 in
>> "Effective D" -- "Know when to use .save"   It would be nice if that
>> potential mistake could be eliminated somehow.  You could perhaps
>> require input ranges to implement transfer semantics, and have them
>> implement a .clone for cases when you really do want to make an
>> aliasing copy.
>
> Good point. I don't have a solution for that. Giving ranges move  
> semantics would probably make for another Effective D tip (or perhaps  
> more... move semantics are pretty brutal).
>
> Another partial solution is to define a different interface for input  
> ranges, one that combines front() and popFront(). Something like  
> popNext. That way, people who use only the primitives empty() and  
> popNext() know they are using a forward range and with hope they'll  
> remember they can't really save copies of it and expect them to  
> "remember" where they are in the input.
>
>
> Andrei

Bicycle shed: Well, since output ranges use 'put', how about 'get' for  
input ranges?