Lots of low hanging fruit in Phobos

[Jakob Ovrum]

On Friday, 7 March 2014 at 01:15:43 UTC, Walter Bright wrote:
> On 3/6/2014 4:43 PM, H. S. Teoh wrote:
>> What about using output ranges?
>
> A great question. I tend to regard output ranges as suitable 
> for a container to expose. An algorithm reads an InputRange, 
> and presents its output as another InputRange. This is so that 
> algorithms can be easily chained together by the user, and the 
> last algorithm in the chain would be 
> std.algorithm.copy(OutputRange).

While I prefer this approach most of the time, I fear it has a 
performance cost over sink-style algorithms (whether they use an 
output range or build an array result). I guess the question is 
whether this cost is generally offset by gains in the memory 
allocation code or not.

> For example, we could implement toStringz() as an algorithm 
> that looks like:
>
>     auto toStringz(S)(S s) {
>         return chain(s, repeat(0, 1))
>     }

std.range.only is more suitable than `repeat` here (and I don't 
know if `chain` would let you chain a range of characters with a 
range of integers):

auto toStringz(S)(S s)
     if (is(Unqual!(ElementType!S) == dchar)) {
     return s.chain('\0'.only());
}

Either way, perhaps the most serious problem is that when using 
`copy` to write the result to an array, both UTF decoding and 
re-encoding takes place (the result is always a range of `dchar`).