Definition of "OutputRange" insuficient

[Christophe Travert]

"monarch_dodra" , dans le message (digitalmars.D:172586), a écrit :
> I was trying to fix a few bugs in algorithm, as well as be more 
> correct in template type specifiers, and I have to say: There is 
> a serious restraint in the definition of an outputRange.
> 
> The current definition of "isOutputRange" is simply that "an 
> output range is defined functionally as a range that supports the 
> operation put".
> 
> The problem with this is this definition is not very useful (at 
> all). Not just because it lacks front/popFront (this is actually 
> OK). It is because it lacks an "empty". This makes it virtually 
> un-useable unless you are blind writing to an infinite output 
> range.
> 
> The proof that it is useless is that NOT A SINGLE ALGORITHM is 
> compatible with output ranges. All algorithms that really only 
> require an "output" systematically actually require 
> "isForwardRange", or, worse yet "isInputRange" (!). This is only 
> because they all make use of range.empty.

OutputRange is designed for infinite output ranges, like output files 
and appender.

Copy is the only algorithm that uses OutputRange. But still, this is 
enough. That enables to do a lot of things, since copy can branch to any 
lazy input range performing all the generic operation you want*.

However, output range with a limited capacity are not taken into 
account. They are partly covered by the input ranges family. Most ranges 
that are output ranges with a capacity are also input ranges. Arguably, 
we may want to cover output ranges with capacity that are not input 
range. This would may make fill cleaner. uninitializedFill would 
be fill with an output range that does not defines a front method, which 
would be much cleaner than using emplace arbitrarily on a range that is 
not designed for that. This also opens the door to an algorithm that 
copy a input range into an output range, but stops when the output range 
is full of the input range is empty, and return both filled output range 
and consumed input range (the input range could be taken by ref). Copy 
could be improved with an additional "StopPolicy" template argument.

To do this, two methods could be added to output ranges, one telling if 
the range is full, and one telling what is the remaining capacity of the 
range (capacity already has a meaning, some other word should be used). 
These methods are like empty and length.

-- 
Christophe

Out of topic foot note:
* After thoughts, one thing you can't do directly in phobos is to modify 
an output range to return a new output range. You are obliged 
to apply the operation on the input range.
For example:
input.map!toString().copy(output);
can't be written:
input.copy(output.preMap!toString());

Creating a modified output range like my (badly named) output.preMap can 
be useful, but may be to marginal to be put in Phobos. With a revamped 
stdio using more ranges, this may become less marginal. map, joiner, 
filter, chain, take and friends, zip and chunks may have a meaning for 
output range with capacity...