Garbage collection, and practical strategies to avoid allocation

[js.mdnq]

Nothing will get done until someone decides to put in the effort 
to fix the problem. D's biggest drawback at this point is the GC 
and one would think with all the smart people around here someone 
would have solved this problem by now.

We need a solution that allows one to "plug and play" different 
allocation strategies. One shouldn't have to rely on any 
particularly bad GC implementation if they don't want to(but as 
of now are forced to). Stop the world GC is just plain crap 
except for the most basic apps. Any app that requires performance 
is going to have issues with this, the reason being simply that 
there are much better ways.


The ability to avoid the GC is of utmost importance for real time 
apps regardless of what some want people to think.  This can't be 
done as because D internally uses the GC. Hence this must be 
worked around. @nogc/@gc has been brought up several times... 
seems like a start and can't hurt.

IMO the best way to deal with the situation is to use manual 
memory management with a GC backend.

e.g., pretend the GC is not there just like the good ol' days. If 
you forget to deallocate something, maybe get a warning from a 
sufficiently intelligent compiler, if the GC is turned on then it 
will clean up for you behind the scenes. If you need performance, 
turn it off or disable it temporarily.

This is the best of both worlds and allows one to easily go from 
one extreme to the other. One can actually implement a pattern to 
allow the user to select one extreme or the other.

One can already do this in D in user code but since the D core 
does not follow this approach it doesn't do one much good unless 
they want to avoid slices, phobos, etc...

I think it will go a long way to get a standard for D regarding 
memory allocation that follows these lines. All new code will be 
written with using the standard and old code will be updated.