GCs in the news

[Chris via Digitalmars-d]

On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Thu, Jul 17, 2014 at 05:28:01PM +0000, Vic via Digitalmars-d 
> wrote:
>> On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander 
>> wrote:
>> >On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
>> >>If GC is so good, why not make it an option, have a base lib 
>> >>w/o GC.
>> >
>> >Much of Phobos already is GC free. The parts that aren't 
>> >should be
>> >easy to convert to use user-supplied buffers. Please add 
>> >enhancement
>> >requests for cases where there isn't a GC-free alternative to 
>> >a
>> >standard library routine.
>> 
>> If that is true, I may even do a $ bounty to make Phobos GC 
>> free.
>> 
>> I may do the same, $ bounty on vibe.d port to GC free.
>> 
>> I don't know D enough to be able to do that, but good news to 
>> me.
> [...]
>
> Over the last year or so, IIRC, there has been a push (a slow 
> but
> nonetheless steady push) to make as much of Phobos GC-free as 
> possible.
> I'd say most (all?) of std.algorithm and std.range should be 
> GC-free by
> now, and probably many of the others can be made GC-free quite 
> easily
> with the tools that we now have.
>
> AFAIK some work still needs to be done with std.string; Walter 
> for one
> has started some work to implement range-based equivalents for
> std.string functions, which would be non-allocating; we just 
> need a bit
> of work to push things through.
>
> DMD 2.066 will have @nogc, which will make it easy to discover 
> which
> remaining parts of Phobos are still not GC-free. Then we'll 
> know where
> to direct our efforts. :-)
>
>
> T

That's good news! See, we're getting there, just bear with us. 
This begs the question of course, how will this affect existing 
code? My code is string intensive.