Generality creep

[Nick Sabalausky (Abscissa)]

On 3/28/19 2:10 PM, Andrei Alexandrescu wrote:
> 
> Yah, for such we need I think a more primitive notion of 
> UnbufferedRange. An unbuffered range of T has only one API:
> 
> bool fetchNext(ref T);
> 
> Note that the user provides all state, which is interesting. The 
> primitives fills the object and moves to the next one. Returns true on 
> success. Returns persistently false at end of range even if called 
> multiple times. An optional interface (for efficiency's sake) would be:
> 
> size_t fetchNextN(scope T[]);
> 
> which fills a full array and returns the number of elements filled.

Something like that is definitely needed. I remember needing to augment 
the existing range concept with something like that when I was dealing 
with crypto hashes. And obviously it'd be very important for I/O steams. 
Having such thing standardized in phobos would be great.

Steve's input on this may be very important, given his work in iopipe.

> Then we'd have input ranges, which have a buffer of at least one 
> element, i.e. today's input ranges. Input ranges that are not forward 
> ranges are liable to reuse their buffers, so after a call to front(), a 
> call to popFront() may overwrite the current front. This is because by 
> construction input ranges that are not forward ranges do not iterate 
> objects in memory, but instead they transfer data from somewhere else 
> into memory, chunkwise.

This sounds reasonable, but I would REALLY like if we could come up with 
some way to actually *prevent* the user from accessing a stored .front 
after the next call to .popFront instead of relying on "programming by 
convention". Because this seems to run in complete opposition to D 
philosophy. A static check would be fantastic if possible, or at least 
injecting an optional run-time check analogous to bounds checking. Not 
sure how feasible either would be, though.