deprecating std.stream, std.cstream, std.socketstream
timon.gehr at gmx.ch
Wed May 16 14:40:26 PDT 2012
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
>> - 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
> 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.
More information about the Digitalmars-d