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

[via Digitalmars-d-bugs]

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

--- Comment #3 from monarchdodra at gmail.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.

The two issues with that are:
1. Copy is "Range to ouput sink". So you can't just do: "copy(1,
myIntegerOutput)"
2. Copy is implemented on top of output range definition and the "put"
primitive.

Unless you had something else in mind in terms of "one-stop function for
implementing data sinks"? I mean (IMO), I see "copy" as pretty much the same
thing as "put", but with reversed args, making it UFCS friendly.

I had honestly wondered about adding a "putInto" into phobos, which is
basically just out reversed:
5.square().putInto(myOuputRange);

--