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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--

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

--- Comment #2 from hsteoh@quickfur.ath.cx ---
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.

--

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

--- Comment #3 from monarchdodra@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);

--

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

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

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

--- Comment #4 from Jonathan M Davis <jmdavisProg@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

--

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

--- Comment #5 from hsteoh@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.

--

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

--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> ---
Hmmmm. Well, that's certainly food for thought. Output ranges are definitely for when you're writing out the final output, not for composability. However, in many of the cases where an output range would be used, copy wouldn't make sense, because the destination is really output (e.g. the console or a file) and not a new input range. So, I question that it makes sense to try and replace output ranges with copy, though I concur that in many cases where you might use an output range, it makes more sense to use an input range and then feed that into an output range if that's what you want.

Regardless, I think that it's something that merits a larger discussion in the newsgroup.

The one thing that I keep meaning to bring up with output ranges is the lack of ability to determine whether they're full (which becomes even more complicated when dealing with stuff like chars where you can't know ahead of time whether it's going to fit thanks to different encodings), but it's certainly never occurred to me that copy could be thought of as a replacement for output ranges.

--

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

--- Comment #7 from monarchdodra@gmail.com ---
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!

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.

--

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

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com

--- Comment #8 from yebblies <yebblies@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.

std.format.formattedWrite is the best thing ever.

--

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

--- Comment #9 from Jonathan M Davis <jmdavisProg@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.

--

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

--- Comment #10 from hsteoh@quickfur.ath.cx ---
Would it make sense to extend the definition of output range to include a .full method?

--