Lots of low hanging fruit in Phobos

[Walter Bright]

On 3/6/2014 4:43 PM, H. S. Teoh wrote:
> On Thu, Mar 06, 2014 at 01:26:46PM -0800, Walter Bright wrote:
>> A major goal for D in the short term is to reduce reliance in Phobos
>> on the GC. I was looking at std.string last night, and I noticed a
>> couple things:
>>
>> 1. The inputs are constrained to being strings. This is overly
>> restrictive, the inputs should be InputRanges.
>>
>> 2. The outputs should be a range, too. In fact, the string functions
>> should become algorithms. Then they won't need to allocate any
>> memory at all.
> [...]
>
> 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).

For example, we could implement toStringz() as an algorithm that looks like:

     auto toStringz(S)(S s) {
         return chain(s, repeat(0, 1))
     }

and use it like this:

     string s = ...;
     char[] buffer = ...;
     s.toStringz.copy(buffer);

Note how the algorithm version of toStringz does not allocate any memory. buffer 
would be the output range, but note how what it actually is is, and how its 
memory is allocated, is selected by the user.

(std.buffer.scopebuffer is ideal for this sort of usage.)

std.file is loaded with calls to toStringz(), each of which leaks memory quite 
unnecessarily. Using an algorithm version of toStringz(), along with 
scopebuffer, will neatly eliminated these leaks.

You might be tempted to think that these are just little leaks, who cares. But I 
recently wrote a D program that did tens of thousands of file operations, and 
those little leaks turned into a raging river.