Am Fri, 28 Mar 2014 02:55:45 -0700 schrieb Walter Bright <newshou...@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.)
