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
