output ranges: by ref or by value?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2010-01-01 14:10:40 -0500, Jason House <jason.james.house at gmail.com> 
> said:
> 
>>> With save() in tow, class ranges and struct ranges can be used the same
>>> way. True, if someone forgets to say
>>>
>>> auto copy = r.save();
>>>
>>> and instead says:
>>>
>>> auto copy = r;
>>>
>>> the behavior will indeed be different for class ranges and struct 
>>> ranges.
>>
>> Or if they completely forgot that bit of convention and omit creating 
>> a variable called save... Also, doesn't use of save degrade 
>> performance for structs? Or does the inliner/optimizer remove the copy 
>> variable altogether?
> 
> I don't think this will be a problem for the optimizer.
> 
> But I say dump save(): it's more trouble than it's worth.
> 
> I'm sure it will be a problem for most programmers, as most will learn 
> and test algorithms with arrays and struct ranges and not classes. 
> "save()" is a detail too easy to miss. The benefit of supporting classes 
> by asking everyone to remember adding save() seems tiny considering you 
> can easily create a struct wrapper if you really need your range to be a 
> class.
> 
> I know that the struct wrapper would probably force more copies of a 
> range than necessary. But there are many ways this could be alleviated. 
> For instance, the struct wrapper could use copy-on-write with a 
> reference counter to detect when a copy is necessary. So while it'd be a 
> little harder to design a range from a class, it'd be easier for 
> everyone to use ranges correctly.
> 

save() is not only for classes. It also distinguishes input ranges from 
forward ranges. It's the primitive that STL didn't define but should have.

Andrei