D without a GC

[bearophile]

Vladimir Panteleev:

> The usual comeback to that is that Phobos depends on the GC, so a great  
> part of the standard library was unusable without memory leaks.

It's not just Phobos, D is designed to work with a GC (see the recent deprecation of "delete"), some features are designed to work with a GC.

Memory management is not a solved problem, it's an open problem still. There is no silver bullet. So my suggestion is to face the situation with a practical point of view and try to attack the problem from all sides at the same time:

- Put in Phobos some simple systems to manage memory manually better, like memory pools and a hyerarchical memory manager.

- Put in Phobos some (sealed?) collections that manage their own memory, useful when you need a collection of data that contain no GC-managed references, like a double[3].

- Keep using in Phobos the idea used often in Tango of offering an optional way to avoid GC allocations. This helps a lot.

- Make the D GC a little more precise:
  http://d.puremagic.com/issues/show_bug.cgi?id=3463

- Add to DMD a compilation switch to list all places where a closure is created:
  http://d.puremagic.com/issues/show_bug.cgi?id=5070

- Add to DMD a compilation switch to turn into syntax errors all situations where the GC is silently used (so [1,2]~[3] becomes a syntax error, etc). (Maybe there is a bug report for this too, I don't know the number).

- Something like @noheap:
  http://d.puremagic.com/issues/show_bug.cgi?id=5219

- Add Variable Length Arrays to D, they are much safer than alloca() and avoid some dynamic array heap allocations, reducing pressure on the GC:
  http://d.puremagic.com/issues/show_bug.cgi?id=5348

- Plan to replace the current GC with a good generational one (and years later with something like G1), because if you have a better GC you have less desire to manage memory manually.

Bye,
bearophile