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
