ideas about ranges

[Steve Teale]

Steven Schveighoffer Wrote:

> 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

Steve,

I'm glad to see that there are others out there who are equally skeptical about ranges..

Your point about Ranges being similar to an early view of OOP is a good one. Just because someone comes up with an interesting concept, it does not mean you need to use it all the time, or even ever if it does not sit well with you.

Steve