ideas about ranges

[Steven Schveighoffer]

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

> Steven Schveighoffer wrote:
>> On Fri, 22 May 2009 17:10:45 -0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> 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.
>>>
>>> Plenty of algorithms work on input ranges.
>>>
>>  I'm confused, by input range you mean a stream?  Because I'm operating  
>> under the assumption that an input range is anything that defines  
>> front, popFront, and empty.  While you can shoehorn a stream into being  
>> an input range, they don't necessarily implement the required elements  
>> easily.  We may be confusing terminology.
>>  Can you name an example of an input range that is a stream, and an  
>> algorithm that mutates the stream in place (thereby requiring ref  
>> elements)?
>
> There isn't. All I'm saying is, we have the following constraints:
>
> 1. Any range should be seamlessly and efficiently used as an input range.

This is the assumption I am challenging.  I don't think you need this  
assumptions for ranges to work.  You can always bolt input range  
functionality on top of a stream range if you want to treat a stream as an  
input range for some reason.  But if foreach doesn't utilize the popNext  
api, then streams require an unnecessary layer on top, just to use foreach  
with them.

-Steve