Another new io library

[Wyatt via Digitalmars-d]

On Thursday, 18 February 2016 at 18:35:40 UTC, Steven 
Schveighoffer wrote:
> On 2/18/16 12:08 PM, Wyatt wrote:
>>
>> 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?
>
> An iopipe is typed however you want it to be.
>
Sorry, sorry, just thinking (too much?) in terms of the 
conceptual underpinnings.

But I don't think we really disagree, either: if you don't give a 
stream a type it doesn't have one "naturally", so it's best to be 
explicit even if you're just asking for raw bytes.  That's all 
I'm really saying there.

> 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.)

> However, you have some issues there :) popFront doesn't return 
> anything.

Clearly, as!() returns the data! ;)

But criminy, I do actually forget that ALL the damn time!  (I 
blame Broadcom.)  The worst part is I think I've even read the 
rationale for why it's like that and agreed with it with much 
nodding of the head and all that. :(

> And I think parsing/processing stream data works better by 
> examining the buffer than shoehorning range functions in there.
>
I think it's debatable.  But part of stream semantics is being 
able to use it like a stream, and my BER toy was in that vein.  
Sorry again, this is probably not the place for it unless you try 
to replace the std.stream for real.

-Wyatt