protocol for using InputRanges

[Johannes Pfau]

Am Fri, 28 Mar 2014 02:55:45 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 3/28/2014 1:32 AM, Johannes Pfau wrote:
> > Ranges have equivalents in other languages:
> > iterators in c++,
> > IEnumerator in c#,
> > Iterator in java
> >
> > all these languages have special stream types for raw data. I don't
> > think it's bad if we also have streams/ranges separate in D.
> 
> 
> Do you see a point to be able to, in an algorithm, seamlessly swap a
> socket with a string?

Sorry, but no. It sure sounds nice first, but I can't really imagine a
use case where I would want any generic algorithms to work directly on a
socket. Having a look on the cheat sheet of std.algorithm 99% of these
algorithms do not make sense to operate on sockets, those that do
(count, until) would be bad in performance terms when operating
directly byte per byte.

You at least want buffered reads when doing IO operations. If you then
extend range interface to give access to an internal buffer you just
reinvented streams.

> 
> empty-front-popFront works with streams and non-streams. Why break
> this?
> 
> 

It 'works' with streams but it's way too slow. You don't want to read
byte-per-byte. Of course you can always implement ranges on top of
streams. Usually these will not provide byte-per-byte access but
efficient higher level abstractions (byLine, byChunk, decodeText).

The point is you can implement ranges on streams easily, but you can't
use ranges as the generic primitive for raw data. What's the element
type of a data range?
ubyte - performance sucks
ubyte[n], ubyte[] now you have a range of ranges, most algorithms wont
work as expected (find, count, ...).

(the call empty/don't call empty discussion is completely unrelated to
this, btw. You can implement ranges on streams either way, but again,
using ranges for raw data streams is not a good idea.)