https://issues.dlang.org/show_bug.cgi?id=8483
--- Comment #5 from hst...@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. --