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

[Artur Skawina]

On 05/16/12 22:58, Steven Schveighoffer wrote:
> On Wed, 16 May 2012 16:38:54 -0400, Artur Skawina <art.08.09 at gmail.com> wrote:
> 
>> On 05/16/12 22:15, Steven Schveighoffer wrote:
>>> I still don't get the need to "add" this to ranges.  The streaming API works fine on its own.
>>
>> This is not an argument against a streaming API (at least not for me), but
>> for efficient ranges. With the API above I can shift tens of gigabytes of
>> data per second between threads. And still use the 'std' range API and
>> everything that works with it...
> 
> But you never would want to.  Don't get me wrong, the primitives here could work for a streaming API (I haven't implemented it that way, but it could be made to work).  But the idea that it must *also* be a std.range input range makes zero sense.

Well, I do want to. For example, I can pass the produced data to *any* range
consumer, it may be as efficient as mine, but will still work reasonably (I just
did a quick test and the difference seems to be about 10G/s less for plain 
front+popFront consumer).

The goal here is: if we could agree on a standard interface then *any* producer and
consumer, including the ones in the std lib could take advantage of this (optional)
feature. It's not so much about function call overhead as /syscall/ and /locking/
costs. Retrieving or writing 100 elements with only one lock-unlock sequence makes
a large difference.

> To me, this is as obvious as not supporting linklist[index];  Sure, it can be done, but who would ever use it?

This is not even related.

Your 'read(ref ubyte[])' approach can actually mean that one more copy of
the data is required. Think writer->range_or_stream->reader -- unless the
reader is already waiting with an empty buffer, the stream has to copy the
data to an internal buffer, which then has to be copied again when a reader
comes around. The 'slice[] = fronts' solution avoids the second copy.
Like I said, depending on the circumstances, sometimes you want one scheme,
sometimes the other. (TBH, right now i can't think of a case where i'd prefer
a non-range based approach; having the same i/f is just so convenient. But 
I'm sure there's one ;) )

artur