[RFC] I/O and Buffer Range

[Steven Schveighoffer]

On Fri, 17 Jan 2014 05:01:35 -0500, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

> BTW I haven't thought of writing into the buffer, but it works exactly  
> the same. It could be even read/write -"discarded" data is written to  
> underlying stream, freshly loaded is read from stream. Now in case of  
> input stream only writes are nop, for output-only reads are nops.
>
> With pinning it makes for cool multi-pass algorithms that actually  
> output stuff into the file.

In my experience, the code/process for a write buffer is significantly  
different than the code for a read buffer. A read/write buffer is very  
difficult to make, because you either need 2 file pointers, or need to  
constantly seek the single file pointer to overwrite the existing data.

>> But as you have it now, isBuffer!OtherBuffer is false. Is this  
>> necessary?
>>
>
> I think I should call it BufferRange from now on. And bring my docs in  
> line. It may make sense to provide naked Buffer itself as a construct  
> (it has simpler interface) and have generic BufferRange wrapper. I'm  
> just not seeing user code using the former - too error prone and  
> unwieldy.

In a sense, I agree. There aren't many things to do directly with a buffer  
(i.e. there will likely be few filters), and a buffer range provides  
enough primitives to make front/popFront/empty trivial.

>> So we can implement buffers that are both ranges and buffers, and will
>> work with std.algorithm without modification (and that's fine and
>> expected by me), but do we need to *require* that? Are we
>> over-specifying?
>
> Random-Access range had to require .front/.back maybe it was  
> over-specification too? Some stuff is easy to index but not "drop off an  
> item at either end". But now it really doesn't matter - if there are  
> such things, they are not random-access ranges.
>
>> Is there a possibility that someone can invent a buffer
>> that satisfies the primitives of say a line-by-line reader, but cannot
>> possibly be a forward range?
>
> I hardly can see that:
> front --> lookahead(1)[0]
> empty --> lookahead(1).length != 0
> popFront --> seek(1) or enforce(seek(1))
>
> save -> well there got to be a way to pin the data in the buffer?
>
> And they surely could be better implemented inside of a specific buffer  
> range.

I'll have to take a closer look at your code to have a reasonable  
response. But I think this looks fine so far.

-Steve