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

[via Digitalmars-d-bugs]

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

Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com

--- Comment #4 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to hsteoh from comment #2)
> In light of recent realizations that output ranges are really only useful
> with specific operations at the end of UFCS chains, such as
> std.algorithm.copy or std.format.formattedWrite (and arguably, the latter
> could be rewritten to return an input range instead), I'm wondering if we
> should just get rid of output ranges altogether and just have .copy be the
> one-stop function for implementing data sinks.

Are there discussions on this? I have seen no discussions or evidence that
there's anything fundamentally flawed with output ranges and put. There's the
problem with std.range.put and UFCS, but that can be fixed by creating a
different function for a range to implement for std.range.put to use rather
than implementing a function call put. What issues are we talking about here
that make output ranges flawed?

- Jonathan M Davis

--