Another new io library

[Wyatt via Digitalmars-d]

On Thursday, 18 February 2016 at 15:44:00 UTC, Steven 
Schveighoffer wrote:
> On 2/17/16 5:54 AM, John Colvin wrote:
>> On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven 
>> Schveighoffer wrote:
>>> On 2/17/16 1:58 AM, Rikki Cattermole wrote:
>>>
>>>> A few things:
>>>> https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
>>>>
>>>> why isn't that used more especially with e.g. window?
>>>> After all, window seems like a very well used word...
>>>
>>> Not sure what you mean.
>>>
>>>> I don't like that a stream isn't inherently an input range.
>>>> This seems to me like a good place to use this abstraction 
>>>> by default.
>>>
>>> What is front for an input stream? A byte? A character? A 
>>> word? A line?
>>
>> Why not just say it's a ubyte and then compose with ranges 
>> from there?
>
> If I provide a range by element (it may not be ubyte), then 
> that's likely not the most useful range to have.
>
I hadn't thought of this before, but if we accept that a stream 
is raw, untyped data, it may be best _not_ to provide a range 
interface directly.  It's easy enough to

alias source = sourceStream.as!ubyte;

anyway, right?

> This is why I think it's better to have the user specifically 
> tell me "this is how I want to range-ify this stream" rather 
> than assume.
>
I think this makes more sense with TLV encodings, too.  Thinking 
of things like:

switch(source.as!(BERType).popFront){
     case(UNIVERSAL|PRIMITIVE|UTF8STRING){
         int len;
         if(source.as!(BERLength).front & 0b10_00_00_00) {
             // X.690? Never heard of 'em!
         } else {
             len = source.as!(BERLength).popFront;
         }
         return source.buffered(len).as!(string).popFront;
     }
     ...etc.
}

Musing: I'd probably want a helper like popAs!() so I don't 
forget popFront()...

-Wyatt