std.stream replacement

[Tyler Jameson Little]

On Saturday, 9 March 2013 at 02:13:36 UTC, Steven Schveighoffer 
wrote:
> On Fri, 08 Mar 2013 20:59:33 -0500, Stewart Gordon 
> <smjg_1998 at yahoo.com> wrote:
>
>> On 07/03/2013 12:07, Steven Schveighoffer wrote:
>> <snip>
>>> I don't really understand the need to make ranges into 
>>> streams.
>> <snip>
>>
>> Ask Walter - from what I recall it was his idea to have 
>> range-based file I/O to replace std.stream.
>
> I hope to convince Walter the error of his ways :)
>
> The problem with this idea, is that there isn't a proven 
> design.  All designs I've seen that involve ranges don't look 
> attractive, and end up looking like streams with an awkward 
> range API tacked on.  I could be wrong, there could be that 
> really great range API that nobody has suggested yet.  But from 
> what I can tell, the desire to have ranges be streams is based 
> on having all these methods that work with ranges, wouldn't it 
> be cool if you could do that with streams too.
>
>> Thikning about it now, a range-based interface might be good 
>> for reading files of certain kinds, but isn't suited to 
>> general file I/O.
>
> I think a range interface works great as a high level 
> mechanism.  Like a range for xml parsing, front could be the 
> current element, popFront could give you the next, etc.  I 
> think with the design I have, it can be done with minimal 
> buffering, and without double-buffering.
>
> But I see no need to use a range to feed the range data from a 
> file.
>
> -Steve

I agree with this 100%, but I obviously am not the one making the 
decision.

My point in resurrecting this thread is that I'd like to start 
working on a few D libraries that will rely on streams, but I've 
been trying to hold off until this gets done. I'm sure there are 
plenty of others that would like to see streams get finished.

Do you have an ETA for when you'll have something for review? If 
not, do you have the code posted somewhere so others can help?

The projects I'm interested in working on are:

- HTTP library (probably end up pulling out some vibe.d stuff)
- SSH library (client/server)
- rsync library (built on SSH library)

You've probably already thought about this, but it would be 
really nice to either unread bytes or have some efficient way to 
get bytes without consuming them. This would help with writing an 
"until" function (read until either a new-line or N bytes have 
been read) when the exact number of bytes to read isn't known.

I'd love to help in testing things out. I'm okay with building 
against alpha-quality code, and I'm sure you'd like to get some 
feedback on the design as well.

Let me know if there's any way that I can help. I'm very 
interested in seeing this get finished sooner rather than later.