output ranges: by ref or by value?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2010-01-02 21:46:57 -0500, "Steven Schveighoffer" 
> <schveiguy at yahoo.com> said:
> 
>> That was the point of the enum.  It would be a synthetic difference, 
>> but  IMO so is save.  If it turns out that the only usable times you 
>> implement  save all look like:
>>
>> auto save() { return *this; }
>>
>> then save gives you nothing.  It's kind of a proof by induction (I 
>> think).
>>
>> You say that algorithm A requires the ability to save the state of a  
>> range.  So I define a function save on a range which cannot be saved 
>> by a  simple assignment (i.e. a file).  I use A on that range, and the 
>> results  are not what I expect or kill performance or consume unneeded 
>> resources,  I'd rather not use algorithm A on that range, negating the 
>> need to define  a save function in the first place.
>>
>> I think that's what we're going to end up with.
> 
> This is making me think...
> 
> First, opening files silently whenever an algorithm feels the need to 
> save its state is just madness. What if the operating system decide to 
> pop a security window when opening a restricted file? What if the file 
> has been deleted or replaced in its directory while your program is 
> still hanging on the old inode?
> 
> One might want to save the position in a file in order to be able to 
> return there later, but when you return there the last thing you 
> actually want to do is to open the file a second time: what you might 
> realistically want is to set the position to what it was before, calling 
> fseek. So perhaps it would be more useful to have both save() to save 
> the current state (the position in a file), and restore() which would 
> restore the saved state (returning to the saved position in a file).

These are implementation matters. save() could lazily save information, 
duplicate the file handle (cheap on many OSs), etc.

> For ranges with reference semantics -- please call them streams! -- 
> save() and restore() would work just as fpos and fseek for files, but 
> they might also not be available like in a TCP stream or in a 
> communication channel between threads.
> 
> For ranges such as array slices, save and restore would just copy the 
> range in one or the other direction. The only reason to have them is so 
> they can be used as streams.

This I don't understand. Array slices' save is:

T[] save(T[] array) { return array; }


Andrei