https://issues.dlang.org/show_bug.cgi?id=8483
--- Comment #9 from Jonathan M Davis <[email protected]> --- (In reply to monarchdodra from comment #7) > In a nutshell, I have issues with an input range being able to be an output > range, because there is no way to determine if it is "full". > > Heck, even if we could, I resent the notion that an output range could be > "full" at all! Arrays are input ranges, and calling put on them fills them rather than appending to them, so yes, they can get full. And given that it's likely not all that uncommon to be dealing with fixed size buffers, I would expect that there would be plenty of cases where you'd want to write to something using ranges, and it could get full. > Honestly, I wish we had never mixed the notion of (Input)Ranges with output > ranges. IMO, we should have had: > -InputRange > -InputRange && hasAssignableElements (writeable output ranges) > -Sinks (like "writeln", or "container.put") > > And to be honest, I've almost never seen anyone use the OutputRange > interface on an input Range. The only case I know of is "copy". And I don't > think it should. I concur. While it might make sense for something to operate as both an input range and an output range (e.g. fill it as an output range and then empty it as an input range), I think that having front work as a way to write to a range rather than it having to having something specific to output ranges was a mistake. Regardless, the simple fact that the closest thing that we have to a built-in output range (arrays) can get full and yet the output range API does not take that into account is a major indicator that output ranges need at least a minor overhaul if not a major one. --
