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

jerro a at a.com
Wed May 16 13:40:09 PDT 2012


> 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;

I think it would be better to have a function that would return
the number of 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.

I like the idea of frontN and popN. But is there any reason why
a type that defines those (let's call it a stream) should also
be a range? I would prefer to have a type that just defines those
two functions, a function that returns the number of available
elements and a functions that tells whether we are at the end of
stream. If you need a range of elements with a blocking popFront,
it's easy to build one on top of it. You can write a functions
that takes any stream and returns a range of element. I think
that's better than  having to write front, popFront, and empty
for every stream.


More information about the Digitalmars-d mailing list