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

[Andrei Alexandrescu]

On 5/16/12 4:40 PM, Timon Gehr wrote:
> 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.

It used to be buffered in fact but that was too much trouble. The fair 
thing to say here is that map relies on the implicit buffering of its input.

Andrei