Phobos Wish List/Next in Review Queue?

Steven Schveighoffer schveiguy at yahoo.com
Mon Nov 28 04:54:07 PST 2011


On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
>> Ranges are not good for reading N bytes from a file
>> descriptor.
>
> Why not? Isn't that exactly what a range is supposed to be good for?

A range has a specific interface:

T front()
void popFront()
bool empty()

An input stream has a specific interface:

size_t read(ubyte[] buffer)
or alternatively:
ubyte[] read(ubyte[] buffer)

How does one map that interface into an input range?  What is T?  I  
remember proposals where there was some extra function setFrontBytes, or  
an additional parameter to front, that allows you to set the number of  
bytes to read.  This seems like trying to fit a square peg in a round hole.

Now, a range fits very well on top of an input stream with a given  
context.  That context defines *what* front() is going to return.  For  
example, the next line of text.

But you still need a well-designed buffered stream interface that a range  
can use to do its work from.  Streams are not going to be the main  
interface for most users, but they will be the tools that range developers  
use to create easily iterated streams.  And when the user wants to read  
data from a file that has no well-defined T that you can define a range  
for, the stream should provide all the tools necessary to read that data.

Now, an output stream *does* fit quite well as a range, since an output  
range's single put method coincides with an ouptut stream's write method.

-Steve


More information about the Digitalmars-d mailing list