ideas about ranges

[Steven Schveighoffer]

On Fri, 22 May 2009 22:35:39 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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