deprecating std.stream, std.cstream, std.socketstream

[H. S. Teoh]

On Wed, May 16, 2012 at 12:48:49PM -0500, Andrei Alexandrescu wrote:
> On 5/16/12 12:34 PM, Steven Schveighoffer wrote:
> >In other words, ranges aren't enough.
> 
> This is copiously clear to me, but the way I like to think about it
> is by extending the notion of range (with notions such as e.g.
> BufferedRange, LookaheadRange, and such) instead of developing an
> abstraction independent from ranges and then working on stitching
> that with ranges.
[...]

One direction that _could_ be helpful, perhaps, is to extend the concept
of range to include, let's tentatively call it, a ChunkedRange.
Basically a ChunkedRange implements the usual InputRange operations
(empty, front, popfront) but adds the following new primitives:

- bool hasAtLeast(R)(R range, int n) - true if underlying range has at
  least n elements left;

- E[] frontN(R)(R range, int n) - returns a slice containing the front n
  elements from the range: this will buffer the next n elements from the
  range if they aren't already; repeated calls will just return the
  buffer;

- void popN(R)(R range, int n) - discards the first n elements from the
  buffer, thus causing the next call to frontN() to fetch more data if
  necessary.

These are all tentative names, of course. But the idea is that you can
keep N elements of the range "in view" at a time, without having to
individually read them out and save them in a second buffer, and you can
advance this view once you're done with the current data and want to
move on.

Existing range operations like popFrontN, take, takeExactly, drop, etc.,
can be extended to take advantage of the extra functionality of
ChunkedRanges. (Perhaps popFrontN can even be merged with popN, since
they amount to the same thing.)

Using a ChunkedRange allows you to write functions that parse a
particular range and return a range of chunks (say, a deserializer that
returns a range of objects given a range of bytes).

Thinking on it a bit further, perhaps we can call this a WindowedRange,
since it somewhat resembles the sliding window protocol where you keep a
"window" of sequential packet ids in an active buffer, and remove them
from the buffer as they get ack'ed (consumed by popN). The buffer thus
acts like a "window" into the next n elements in the range, which can be
"slid forward" as data is consumed.


T

-- 
Having a smoking section in a restaurant is like having a peeing section
in a swimming pool. -- Edward Burr