On Wed, 06 Mar 2013 19:08:40 -0500, Stewart Gordon <smjg_1...@yahoo.com>
wrote:
On 06/03/2013 16:36, Steven Schveighoffer wrote:
On Tue, 05 Mar 2013 18:24:22 -0500, BLM768 <blm...@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
