GCs in the news

[Brad Anderson via Digitalmars-d]

On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
> The key to making D's GC acceptable lies in two factors I 
> believe.
>
> 1. Improve the implementation enough so that you will only be 
> impacted by GC in extermely low memory or real time 
> environments.
> 2. Defer allocation more and more by using ranges and 
> algorithms more, and trust that compiler optimisations will 
> make these fast.
>
> The big, big offender I believe for extra allocations is 
> functions which return objects, rather than functions which 
> write to output ranges. The single most common occurence of 
> this is something like this is toString. Instead of writing 
> this...
>
> string toString() {
>     // Allocations the user of the library has no control over.
>     return foo.toString() ~ bar.toString() ~ " something else";
> }
>
> I believe you should always, always instead write this.
>
> // I left out the part with different character types.
> void writeString(OutputRange)(OutputRange outputRange)
> if (isOutputRange!(OutputRange, char)) {
>     // Allocations controlle by the user of the library,
>     // this template could appear in a @nogc function.
>     foo.writeString(outputRange);
>     bar.writeString(outputRange);
>
>     "something else".copy(outputRange);
> }
>

I agreed with this for awhile but following the conversation here 
<https://github.com/D-Programming-Language/phobos/pull/2149> I'm 
more inclined to think we should be adding lazy versions of 
functions where possible rather than versions with OutputRange 
parameters. It's more flexible that way and can result in even 
fewer allocations than even OutputRange parameters would have 
(i.e. you can have chains of lazy operations and only allocate on 
the final step, or not at all in some cases).

Laziness isn't appropriate or possible everywhere but it's much 
easier to go from lazy to eager than the other way around.

> [...]