iopipe alpha 0.0.1 version

[Dmitry Olshansky]

On Tuesday, 24 October 2017 at 19:05:02 UTC, Martin Nowak wrote:
> 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


I had a design like that except save returned a “mark” (not full 
range) and there was a slice primitive. It even worked with 
patched std.regex, but at a non-zero performance penalty.

I think that maintaining the illusion of a full copy of range 
when you do “save” for buffered I/O stream is too costly. Because 
a user can now legally advance both - you need to RC buffers 
behind the scenes with separate “pointers” for each range that 
effectively pin them.

> 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.