buffered input

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> I hereby suggest we define "buffered input range of T" any range R that 
> satisfies the following conditions:
> 
> 1. R is an input range of T[]
> 
> 2. R defines a primitive shiftFront(size_t n). The semantics of the 
> primitive is that, if r.front.length >= n, then shiftFront(n) discards 
> the first n elements in r.front. Subsequently r.front will return a 
> slice of the remaining elements.
> 
> 3. R defines a primitive appendToFront(size_t n). Semantics: adds at 
> most n more elements from the underlying stream and makes them available 
> in addition to whatever was in front. For example if r.front.length was 
> 1024, after the call r.appendToFront(512) will have r.front have length 
> 1536 of which the first 1024 will be the old front and the rest will be 
> newly-read elements (assuming that the stream had enough data). If n = 
> 0, this instructs the stream to add any number of elements at its own 
> discretion.

I don't see a clear need for the two to be separate. Could they fold into popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary popFront() discards all and loads any number it pleases.

> This is it. I like many things about this design, although I still fear 
> some fatal flaw may be found with it.
>
> With these primitives a lot of good operating operating on buffered 
> streams can be written efficiently. The range is allowed to reuse data 
> in its buffers (unless that would contradict language invariants, e.g. 
> if T is invariant), so if client code wants to stash away parts of the 
> input, it needs to make a copy.

Some users would benefit if they could just pass in a buffer and say "fill'er up".

> One great thing is that buffered ranges as defined above play very well 
> with both ranges and built-in arrays - two quintessential parts of D. I 
> look at this and say, "this all makes sense". For example the design 
> could be generalized to operate on some random-access range other than 
> the built-in array, but then I'm thinking, unless some advantage comes 
> about, why not giving T[] a little special status? Probably everyone 
> thinks of contiguous memory when thinking "buffers", so here 
> generalization may be excessive (albeit meaningful).

Contiguous, yes. But I'd rather see front() exposing, say, a circular buffer so that appendToFront(n) reallocates only when n > buf.length.

-- 
Tomek