Michel Fortin wrote:
On 2010-01-01 17:54:12 -0500, Andrei Alexandrescu
<[email protected]> 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
