Is this range behaviour correct?

[Andrea Fontana]

On Thursday, 14 March 2013 at 14:51:42 UTC, monarch_dodra wrote:
> 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.

Yes it was just a way to avoid dead cursors locked at end of 
results :)
I add a feature request hoping they add a method to clone cursors 
(i think/hope it's possible)

In the meanwhile you have to do query again.