Stream Proposal

[Jonas Drewsen]

On 12/03/11 04.54, Daniel Gibson wrote:
> Am 12.03.2011 04:40, schrieb dsimcha:
>> On 3/11/2011 10:14 PM, Jonathan M Davis wrote:
>>> On Friday, March 11, 2011 18:29:42 dsimcha wrote:
>>>> 3. std.stdio.File should be moved to the new stream module but publicly
>>>> imported by std.stdio. It should also grow some primitives that make it
>>>> into an input range of characters. These can be implemented with
>>>> buffering under the hood for efficiency.
>>>
>>> ??? Why? File is not a stream. It's a separate thing. I see no reason
>>> to combine
>>> it with streams. I don't think that the separation between std.stdio and
>>> std.stream as it stands is a problem. The problem is the design of
>>> std.stream.
>>>
>>> - Jonathan M Davis
>>
>> Isn't file I/O a pretty important use case for streams, i.e. the main
>> one?
>
> Network I/O is also very important.
>
> BTW, Andrei proposed a stream API a while ago[1] which was also
> discussed back than - can't we use that as a basis for further
> discussions about streams?
>
> By the way, I'd prefer class-based streams (and even Andrei proposed
> that in aforementioned discussion).
>
> Cheers,
> - Daniel
>
> [1]
> http://lists.puremagic.com/pipermail/digitalmars-d/2010-December/thread.html#91169

I like this proposal.

And regarding the question about non-blocking streams then I'm 
definitely a proponent of this. The standard C++ library streaming 
support is really not geared towards this and therefore it is difficult 
to get non-blocking streaming right.

/Jonas