On 2/18/16 4:02 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/18/16 2:53 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
But the concept of what constitutes an "item" in a stream may not be
the "element type". That's what I'm getting at.
Hmm, I guess I'm not seeing it. Like, what even is an "item" in a
stream? It sort of precludes that by definition, which is why we
have to give it a type manually. What benefit is there to giving the
buffer type separately from the window that gives you a typed slice
into it? (I like that, btw.)
An "item" in a stream may be a line of text, it may be a packet of
data, it may actually be a byte. But the compiler requires we type the
buffer as something rigid that it can work with.
The elements of the stream are the basic fixed-sized units we use (the
array element type). The items are less concrete.
[...]
But array elements don't necessarily have to be fixed-sized, do they?
For example, an array of lines can be string[] (or const(char)[][]). Of
course, dealing with variable-sized items is messy, and probably rather
annoying to implement. But it's *possible*, in theory.
But the point of a stream is that it's contiguous data. A string[] has
contiguous data that are pointers and lengths of a fixed size
(sizeof(string) is fixed).
This is not how you'd get data from a file or socket.
Since this library doesn't discriminate what the data source provides
(it will accept string[] as window type), it's possible. In this case,
the element type might make sense as the range front type, but it's not
a typical case. However, it might be interesting as, say, a message
stream from one thread to another.
-Steve
