ideas about ranges

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> 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.
> 
> I believe there is indeed a terminology problem. To me, "input range" == 
> "stream" == "socket" == "bridge that is sinking under your feet as you 
> walk it". So to me there exists no "stream range". That to me is an 
> "input range".
> 
>> But if foreach doesn't utilize the popNext api, then streams require 
>> an unnecessary layer on top, just to use foreach with them.
> 
> We can arrange that foreach uses popNext, but it must be worth it.
> 
> Andrei

> On Fri, 22 May 2009 21:50:03 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> 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.
>>
>> I believe there is indeed a terminology problem. To me, "input range" 
>> == "stream" == "socket" == "bridge that is sinking under your feet as 
>> you walk it". So to me there exists no "stream range". That to me is 
>> an "input range".
> 
> 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?

>>> But if foreach doesn't utilize the popNext api, then streams require 
>>> an unnecessary layer on top, just to use foreach with them.
>>
>> We can arrange that foreach uses popNext, but it must be worth it.
> 
> I can't say for certain that it is, but you definitely will know if when 
> you start implementing ranges based on stuff like files, and things just 
> seem difficult to implement or have unsolvable problems.  I guess we 
> wait and see.

One hopeful element is that there are usually more containers than 
streams/files. Besides, most streams are buffered. So maybe things 
aren't that bad.


Andrei