On Tuesday, 24 October 2017 at 14:47:02 UTC, Steven Schveighoffer wrote:
iopipe provides "infinite" lookahead, which is central to its purpose. The trouble with bolting that on top of ranges, as you said, is that we have to copy everything out of the range, which necessarily buffers somehow (if it's efficient i/o), so you are double buffering. iopipe's purpose is to get rid of this unnecessary buffering. This is why it's a great fit for being the *base* of a range.

In other words, if you want something to have optional lookahead and range support, it's better to start out with an extendable buffering type like an iopipe, and bolt ranges on top, vs. the other way around.

Arguably this it is somewhat hacky to use a range as end marker for slicing sth., but you'd get the same benefit, access to the random buffer with zero-copying.

auto beg = rng.save; // save current position
auto end = rng.find("bla"); // lookahead using popFront
auto window = beg[0 .. end]; // get a random access window to underlying buffer

So basically forward ranges with slicing.
At least that would require to extend all algorithms with `extend` support, though likely you could have a small extender proxy range for IOPipes.

Note that rng could be a wrapper around unbuffered IO reads.

Reply via email to