is d-runtime non-gc safe?

[Steven Schveighoffer]

On Mon, 05 Dec 2011 11:34:18 -0500, Hans Uhlig <hans.uhlig at teamaol.com>  
wrote:

> Ok, this is probably a silly question but why are the array appending  
> operations dependent on the GC. Why cant you allocate from a fixed pool?  
> or can you it just requires writing your own malloc/free implementation?

This might help:

http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

To summarize:

arr ~= 1;

What does this do?  It appends 1 to the slice.  So what happens if that  
new element can't fit in the given memory block?  Given how d slices work,  
you have no idea whether there is another slice that refers to that same  
original slice.  Not invalidating other slices is a requirement of  
appending.  So you have to allocate new memory, and leave the old memory  
in tact.

But what if nobody else is referencing that memory?  It becomes leaked.   
This is why the GC is necessary for array appending *as defined by the D  
spec* to work.  Without the GC, you must either deallocate on appending,  
making all other slices to the old data invalid, or you must leak memory.

Now, there are other ways to do array implementations.  For instance, an  
array could be a full-blown reference type, and the actual heap data  
hidden by the array.  Then you can avoid leaking, but that still doesn't  
implement all the features of D slices.  It cannot be a drop-in  
replacement.

In reality, there is no way to provide the same features as D's arrays and  
slices without a GC.  So simply put, you need to redesign your code not to  
use those features.  Hence the project of making druntime avoid all  
GC-requiring features.

-Steve