std.stream replacement

[Steven Schveighoffer]

On Wed, 06 Mar 2013 19:08:40 -0500, Stewart Gordon <smjg_1998 at yahoo.com>  
wrote:

> On 06/03/2013 16:36, Steven Schveighoffer wrote:
>> On Tue, 05 Mar 2013 18:24:22 -0500, BLM768 <blm768 at gmail.com> wrote:
> <snip>
>>> Create a range operation like "r.takeArray(n)". You can optimize it to
>>> take a slice of the buffer when possible.
>>
>> This is not a good idea.  We want streams to be high performance.
>> Accepting any range, such as a dchar range that outputs one dchar at a
>> time, is not going to be high performance.
> <snip>
>
> That certain specific types of range can't implement a given operation  
> efficiently isn't a reason to reject the idea.

Sorry, but that is.

If we make it so streams are implicitly built out of low-performance  
ranges, they will be built out of low performance ranges.

There is always a mechanism to build a stream out of a range, it shouldn't  
be implicit.  Not every range makes a good stream.

> But thinking about it now, maybe what we need is the concept of a "block  
> input" range, which is an input range with the addition of the takeArray  
> method.  Of course, standard D arrays would be block input ranges.  Then  
> (for example) a library that reads a binary file format can be built to  
> accept a block input range of bytes.

I don't really understand the need to make ranges into streams.  Streams  
require a completely separate interface.  An object can be a range and a  
stream (e.g. array), but to say a stream is a specific kind of range, when  
ranges have nothing significant that streams need (front, popFront), is  
just "range fever".  Not everything is a range.

The range interface and the stream interface are orthogonal.  There is no  
overlap.

-Steve