On 05/16/2012 11:08 PM, Andrei Alexandrescu wrote:
On 5/16/12 1:00 PM, Steven Schveighoffer wrote:
What I think we would end up with is a streaming API with range
primitives tacked on.
- empty is clunky, but possible to implement. However, it may become
invalid (think of reading a file that is being appended to by another
process).
- popFront and front do not have any clear definition of what they refer
to. The only valid thing I can think of is bytes, and then nobody will
use them.
That's hardly saying it's "range based". I refuse to believe that people
will be thrilled by having to 'pre-configure' each front and popFront
call in order to get work done. If you want to try and convince me, I'm
willing to listen, but so far I haven't seen anything that looks at all
appetizing.
Where the two meet is in the notion of buffered streams. Ranges are by
default buffered, i.e. user code can call front() several times without
an intervening popFront() and get the same thing. So a range has by
definition a buffer of at least one element.
I don't think this necessarily holds. 'front' might be computed on the
fly, as it is done for std.algorithm.map.
That makes the range interface unsuitable for strictly UNbuffered
streams. On the other hand, a range could no problem offer OPTIONAL
unbuffered reads (the existence of a buffer does not preclude
availability of unbuffered transfers).
So to tie it all nicely I think we need:
1. A STRICTLY UNBUFFERED streaming abstraction
2. A notion of range that supports unbuffered transfers.
Andrei
