Is this range behaviour correct?

[monarch_dodra]

On Thursday, 14 March 2013 at 14:29:59 UTC, Andrea Fontana wrote:
> On Thursday, 14 March 2013 at 13:58:56 UTC, monarch_dodra wrote:
>> On Thursday, 14 March 2013 at 13:20:51 UTC, Andrea Fontana 
>> wrote:
>>> On Thursday, 14 March 2013 at 12:29:26 UTC, Andrei 
>>> Alexandrescu wrote:
>>>> On 3/14/13 6:45 AM, Andrea Fontana wrote:
>>>>> On Thursday, 14 March 2013 at 10:08:53 UTC, Andrea Fontana 
>>>>> wrote:
>>>>>> I'm trying to implement a db cursor as simple InputRange. 
>>>>>> I can't
>>>>>> implement as forward range because using c-api I can't 
>>>>>> clone/save cursor.
>>>> Add .save() to it.
>>>>
>>>> Andrei
>>>
>>> I can't add save and create a forward range: c-api doesn't 
>>> allow me to clone db cursor.
>>
>> But think about it. You say you can't save, but you want pass 
>> by value to preserve state. If you can preserve state, doesn't 
>> that mean you just saved?
>>
>> Once you've passed your "can't preserve state" to a foreach, 
>> then your range is consumed. So yes, it is correct behavior.
>>
>> Most input ranges should model reference semantics when 
>> passed/copied by value. If somebody modifies the range, all 
>> ranges are affected. The tough part is usually preserving 
>> correct state.
>
> I was hoping there's something I didn't know like rewind() to 
> implement :)
>
> Ok, I'll pray db developer to add a clone method or I'll use 
> something like
>
> auto res = cursor.array(); if needed

You *could* add rewind to your range, but it isn't quite the same 
as save: Rewind means you can move back and forth in your view of 
the file (or cursor/db), but it does not mean you can actually 
*duplicate* (save) your range, to have two distinct ranges with a 
distinct view of the your db.

For example, while the interface is different, a C "FILE*" is 
what you'd call a rewindable input range with reference semantics.