On 2010-01-02 09:59:51 -0500, Andrei Alexandrescu
<[email protected]> said:
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.
I'm not expecting a miracle from it either, it'd just be much less confusing.
You could say that assignment of an input stream might or might not
save its state (depending on the stream type) so you must call save()
to save the state when working with streams, but ranges are guarantied
to save their state on assignment, thus behaving more predictably and
just like arrays. So if you're working only with ranges, not streams,
you never need to worry about save().
A similar option would be to have both input ranges and input streams:
* input range: by value semantics, no need for save()
* input stream: by reference semantics
A pointer to an input range would thus automatically qualify as an
input stream, so it's easy to give an input range to a function taking
an input stream. Well, except for stack-allocated ranges in SafeD for
which you can't create a pointer. This pretty much break the idea, I
think.
--
Michel Fortin
[email protected]
http://michelf.com/
