On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Fri, 22 May 2009 17:10:45 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
