"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...
