manual memory management

[Rob T]

Yes I can see in your example why removing the GC fully will be 
difficult to deal with.

I am not actually against the use of the GC, I was only wondering 
if it could be fully removed. I too did not at first agree with 
the GC concept, thinking the same things you mention. I still 
have to consider performance issues caused by the GC, but the 
advantage is that I can do things that before I would not even 
bother attempting because the cost was too high. The way I 
program has changed for the better, there's no doubt about it.

So if the GC cannot be removed fully, then there's no point 
trying to fully remove it, and performance issues have to be 
solved through improving the GC implementation, and also with 
better selective manual control methods.

As for the claims made that D's GC is "optional", that message is 
coming from various sources one encounters when reading about D 
for the first time.

For example:
http://www.drdobbs.com/tools/new-native-languages/232901643
"D has grown to embrace a wide range of features — optional 
memory management (garbage collection), ..."

Sure you can "optionally" disable the GC, but it means certain 
fundamental parts of the language will no longer be usable, 
leading to misconceptions that the GC is fully optional and 
everything can be made to work as before.

I know D's documentation is *not* claiming that the GC is 
optional, you get that impression from reading external sources 
instead, however it may be a good idea to counter the possible 
misconception in the FAQ.

Improved documentation will also help those who want to do 
selective manual memory management. As it is, I cannot say for 
certain what parts of the language require the use of the GC 
because the specification either leaves this information out, or 
is not specified clearly enough.

--rt