output ranges: by ref or by value?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2010-01-01 17:54:12 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Michel Fortin wrote:
>>> What I'd do instead is somehow make input ranges non-copyable. They 
>>> could be either passed by ref or moved, never copied. This way they 
>>> would still behave exactly like array slices, only not copyable, and 
>>> you get a compile-time error if you try to copy them which is 
>>> infinitely better than a subtle change in behavior.
>>
>> I tried that, it makes input ranges next to unusable.
> 
> I think I can see why. You can't have ref member and local variables 
> like in C++, so it's pretty hard to use references.
> 
> 
>> save() is an imperfect but workable solution.
> 
> save() is an workable but error-prone solution.
> 
> Perhaps we could mitigate this by making people more aware of the 
> difference instead. Couldn't we rename "input range" for "input stream"?
> 
> Currently you have ranges that behave one way and ranges that behave the 
> other way, which is confusing. Having a different name for both would 
> emphasize there is a difference. With different names, you're guarantied 
> to get the "what's the difference?" question from newbies.
> 
> And it's simple to explain: "You can often use ranges and streams 
> interchangeably, but for that to work you must use save() when you need 
> a copy of the current state. Also, not all streams support save(). It's 
> good practice to always use save() so that algorithms work for both for 
> ranges and streams."

That's an idea, and names are powerful, but I think it's reasonable to 
not expect miracles from that name change. It has disadvantages too - 
"input range" vs. "forward range"  clarifies there's a conceptual 
relationship between the two, whereas "streams" are different from 
anything else.

Andrei