iopipe alpha 0.0.1 version

[Martin Nowak]

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.