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

[via Digitalmars-d-bugs]

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

--- Comment #9 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(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.

--