[RFC] I/O and Buffer Range

[Steven Schveighoffer]

On Thu, 16 Jan 2014 17:28:31 -0500, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

>
> The other way around :) 4 code units - 1 code point.

I knew that was going to happen :)

>> This would be a key addition for ANY type in order to properly work with
>> shared. BUT, I don't see how it works safely generically because you
>> necessarily have to cast away shared in order to call the methods. You
>> would have to limit this to only working on types it was intended for.
>
> The requirement may be that it's pure or should I say "well-contained".  
> In other words as long as it doesn't smuggle references somewhere else  
> it should be fine.
> That is to say it's 100% fool-proof, nor do I think that essentially  
> simulating a synchronized class is a always a good thing to do...

I think you meant *not* 100% :) But yeah, regardless of how generalized it  
is, this is likely the best path. I think this is the tack that  
std.stdio.File takes anyway, except it's using FILE *'s locking mechanism.

>
> Convenient to work with does ring good to me. I simply see no need to  
> reinvent std.algorithm on buffers especially the ones that just scan  
> left-to-right.
> Example would be calculating a checksum of a stream (say data comes from  
> a pipe or socket i.e. buffered). It's a trivial application of  
> std.algorithm.reduce and there no need to reinvent that wheel IMHO.
>

I again think I am being misunderstood. Example might be appropriate:

struct Buffer {...} // implements BOTH forward range and Buffer primitives

struct OtherBuffer {...} // only implements Buffer primitives.

If isBuffer is modified to not require isForwardRange, then both Buffer  
and OtherBuffer will work as buffers, but only Buffer works as a range.

But as you have it now, isBuffer!OtherBuffer is false. Is this necessary?

So we can implement buffers that are both ranges and buffers, and will  
work with std.algorithm without modification (and that's fine and expected  
by me), but do we need to *require* that? Are we over-specifying? Is there  
a possibility that someone can invent a buffer that satisfies the  
primitives of say a line-by-line reader, but cannot possibly be a forward  
range?

-Steve