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
