On 2/17/16 9:52 AM, Adam D. Ruppe wrote:
On Wednesday, 17 February 2016 at 10:54:56 UTC, John Colvin wrote:
Why not just say it's a ubyte and then compose with ranges from there?
You could put a range interface on it... but I think it would be of very
limited value. For one, what about fseek? How does that interact with
the range interface?
seeking a stream is not a focus of my library. I'm focusing on raw data
throughput for an established pipeline that you expect not to move around.
A seek would require resetting the pipeline (something that is possible,
but I haven't planned for it).
Or, what about reading a network interface where you get variable-sized
packets?
This I HAVE planned for, and it should work quite nicely. I agree that
providing a by-default range interface may not be the most useful thing.
Copying it into a buffer is probably the most sane... but it is a
wasteful copy if your existing buffer has enough space. But how to you
say that to a range? popFront takes no arguments.
The asInputRange adapter in iopipe/bufpipe.d provides the following
crude interface:
1. front is the current window
2. empty returns true if the window is empty.
3. popFront discards the window, and extends in the next window.
With this, any ioPipe can be turned into a crude range. It should be
good enough for things like std.algorithm.copy. And in the case of
byLine, it allows one to create an iopipe that caters to creating a
range, while also giving useful functionality as a pipe.
I'm on the fence as to whether all ioPipes should be ranges. Yes, it's
easy to do (though a lot of boilerplate, you can't UFCS this), but I
just can't see the use case being worth it.
Ranges are great for a sequence of data that is the same type on each
call. Files, however, tend to have variable length (which you might want
to skip large sections of) and different types of data as you iterate
through them.
Very much agree.
I find std.stdio's byChunk and byLine to be almost completely useless in
my cases.
byLine I find useful (think of grep), byChunk I've never found a reason
to use.
-Steve
