[Issue 8483] Definition of isOutputRange warped due to "put" implementation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8483

--- Comment #5 from hsteoh at quickfur.ath.cx ---
I didn't say anything was *flawed* with output ranges. I just said that they
are not *as* useful because, being sinks, any code that uses them will
terminate the processing chain, making it non-composable with any subsequent
data processing. IME, I've also found that code that takes output ranges as
parameters tend to be limited in reusability, and tends to uglify downstream
code since you have to store the data somewhere, or use hacks to allow further
processing of data, etc..

In fact, all cases of output range usage that I encountered while writing
range-based code can be more profitably refactored to return input ranges
instead, and use std.algorithm.copy for when I actually want to use an output
range. This makes the majority of the code composable, and therefore much more
reusable, than if I had used output ranges everywhere. Basically, anything that
looks like func(inputRange, outputRange) can be rewritten as
newFunc(inputRange).copy(outputRange), where newFunc returns an input range
instead of writing the results to an output range.

So, since anything that takes an output range can always be rewritten as
something that returns an input followed by std.algorithm.copy, it follows that
the usefulness of output ranges seems to be restricted to std.algorithm.copy.
Being such, then, it seems that the logical next step is to eliminate the
concept altogether, and just have std.algorithm.copy implement all the
semantics of output ranges.

--