ideas about ranges

[Steven Schveighoffer]

On Fri, 22 May 2009 15:55:52 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:

>> I'm not convinced that range is the best fit for ref'd data anyways,  
>> opApply is much more adept at it.
>
> If ranges aren't fit to mutate stuff, we failed. Many algorithms in  
> std.algorithm mutate their data and I can't bring myself to think how  
> I'd implement them all with opApply.

I misspoke, what I meant was maybe range isn't the best fit for *ref  
iteration using foreach*.  Of course, having ranges that can ref data is  
important for other uses of ranges.

So would it be acceptable to change foreach to use either the popNext api  
or the opApply api, and not have foreach support the input range api?   
That was my ponder.

>
>> How does implementation of popNext look?
>>  bool popNext(R)(R r, ref ElementType!R elem)
>>      if (isForwardRange!R)
>> {
>>      if (r.empty)
>>          return false;
>>      elem = r.front();
>>      r.popFront();
>>      return true;
>> }
>
> It forces a copy whenever you want to take a look at something.

Yes, and in the case of:

foreach(x; r)

You are going to do copying.  This is what I'm guessing would be the  
standard model for getting data from a stream using foreach (it is now,  
with opApply).

In the case of:

foreach(ref x; r)

you *need* a reference, so at this point you'd need to use the opApply or  
input-range style (front, popfront, empty) api to run foreach.  If streams  
don't support ref data (which they shouldn't IMO), this is a compiler  
error.

I'm concentrating mostly on usages with foreach, not algorithms.  If we  
are to have streams that fit into the range model, then they need to be  
foreach'able.  I don't know that they need a lot of support to feed into  
std.algorithm as reference data.  I.e. you aren't going to sort a network  
stream.

-Steve