Another new io library

[Steven Schveighoffer via Digitalmars-d]

On 2/18/16 4:02 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 2/18/16 2:53 PM, Wyatt wrote:
>>> On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
>>
>>>> But the concept of what constitutes an "item" in a stream may not be
>>>> the "element type". That's what I'm getting at.
>>>>
>>> Hmm, I guess I'm not seeing it.  Like, what even is an "item" in a
>>> stream?  It sort of precludes that by definition, which is why we
>>> have to give it a type manually.  What benefit is there to giving the
>>> buffer type separately from the window that gives you a typed slice
>>> into it? (I like that, btw.)
>>
>> An "item" in a stream may be a line of text, it may be a packet of
>> data, it may actually be a byte. But the compiler requires we type the
>> buffer as something rigid that it can work with.
>>
>> The elements of the stream are the basic fixed-sized units we use (the
>> array element type). The items are less concrete.
> [...]
>
> But array elements don't necessarily have to be fixed-sized, do they?
> For example, an array of lines can be string[] (or const(char)[][]). Of
> course, dealing with variable-sized items is messy, and probably rather
> annoying to implement.  But it's *possible*, in theory.

But the point of a stream is that it's contiguous data. A string[] has 
contiguous data that are pointers and lengths of a fixed size 
(sizeof(string) is fixed).

This is not how you'd get data from a file or socket.

Since this library doesn't discriminate what the data source provides 
(it will accept string[] as window type), it's possible. In this case, 
the element type might make sense as the range front type, but it's not 
a typical case. However, it might be interesting as, say, a message 
stream from one thread to another.

-Steve