output ranges: by ref or by value?

[Andrei Alexandrescu]

Jason House wrote:
> Andrei Alexandrescu wrote:
> 
>> Philippe Sigaud wrote:
>>> On Thu, Dec 31, 2009 at 16:47, Michel Fortin <michel.fortin at michelf.com
>>> <mailto:michel.fortin at michelf.com>> wrote:
>>>
>>>     On 2009-12-31 09:58:06 -0500, Andrei Alexandrescu
>>>     <SeeWebsiteForEmail at erdani.org
>>>     <mailto:SeeWebsiteForEmail at erdani.org>> said:
>>>
>>>         The question of this post is the following: should output ranges
>>>         be passed by value or by reference? ArrayAppender uses an extra
>>>         indirection to work properly when passed by value. But if we
>>>         want to model built-in arrays' operator ~=, we'd need to request
>>>         that all output ranges be passed by reference.
>>>
>>>
>>>     I think modeling built-in arrays is the way to go as it makes less
>>>     things to learn. In fact, it makes it easier to learn ranges because
>>>     you can begin by learning arrays, then transpose this knowledge to
>>>     ranges which are more abstract and harder to grasp.
>>>
>>>
>>> I agree. And arrays may well be the most used range anyway.
>> Upon more thinking, I'm leaning the other way. ~= is a quirk of arrays
>> motivated by practical necessity. I don't want to propagate that quirk
>> into ranges. The best output range is one that works properly when
>> passed by value.
> 
> I worry about a growing level of convention with ranges.  Another recent 
> range thread discussed the need to call consume after a successful call to 
> startsWith.  If I violated convention and had a range class, things would 
> fail miserably.  There would be no need to consume after a successful call 
> to startsWith and the range would have a random number of elements removed 
> on an unsuccessful call to startsWith. I'm pretty sure that early 
> discussions of ranges claimed that they could be either structs and classes, 
> but in practice that isn't the case.

I am implementing right now a change in the range interface mentioned in 
http://www.informit.com/articles/printerfriendly.aspx?p=1407357, namely: 
add a function save() that saves the iteration state of a range.

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.


Andrei