On Fri, 22 May 2009 22:35:39 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
OK, I can see you're not going to alter your opinion, so I'll stop
debating. I respectfully disagree with your definitions.
I'm using STL's definitions. I'd be glad to depart if there was a solid
reason. How would you name things?
I reread the chapter on iterators in my C++ book. I was convinced that I
would see something to fuel my beliefs.
I'm now convinced that ranges can stay as is. Here is why:
I was focusing on a stream range as a more basic range than an input
range. However, I wasn't thinking about the whole picture. There are
more than just input streams. There are output streams and input/output
streams. It makes sense to support all of them, not just input streams.
So really, I'm thinking of a different tree of entities, which already
exist: streams! That is, the unification of ranges and streams really
isn't necessary. You can wrap a stream as an input, output, or forward
range, and deal with the shoehorning (and buffer issues) when you really
need it. I don't think viewing streams as ranges is going to be a useful
idiom unless you need to convert from one world to the other. So trying
to find a way to make files be ranges might be simply an overenthusiastic
view of ranges, similar to how people try to make everything object
oriented when they learn how OO design works.
As far as foreach, we still have opApply for streams (or shoehorning if
you need range-ification).
However, out of all this may come one interesting idea: popNext
(specifically the 'bool popNext(ref T val)' form).
Note that there are a couple of advantages to using popNext with foreach:
1. Multiple variables, and easy overloading. i.e. foreach(int idx, T val;
range) would be possible (and much less cumbersome than opApply!).
2. 1 function call per loop instead of 3. This may have a distinct
advantage if you absolutely have to use a virtual method, or your range
must call virtual methods on it's container.
I still don't know how to make ref values work with popNext without using
pointers. It would be nice to have a rebindable ref type.
I thought of this syntax, does this seem appealing at all?
int i = 5, j = 6;
ref int ri = i;
ri = 7;
assert(i == 7);
ri.& = &j;
ri = 8;
assert(j == 8);
type of ref.& is *not* a pointer, the arithmetic operators are not defined
for it, and it can't be assigned to a pointer (although it can be assigned
from a pointer).
You also need to be able to pass the type of ref.& to rebind references
inside a popNext function.
If we could solve these problems, we might have a better case of being
able to get rid of opApply.
-Steve
