deprecating std.stream, std.cstream, std.socketstream

[Timon Gehr]

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