On Thu, 16 Jan 2014 17:28:31 -0500, Dmitry Olshansky
<dmitry.o...@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
