On 12/20/2011 11:48 AM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 11:21:41 Froglegs wrote:
I've only recently tried D out, but what I'd like to see..
-GC being truly optional
-being able to specify if the standard library should use GC or
not, perhaps with allocators
Some aspects of D will _always_ require a GC or they won't work.
This is not a huge problem. They just wont work if the programmer
chooses not to use the GC. There is nothing absolutely essential to
writing working D programs that requires the GC.
Array
concatenation would be a prime example. I believe that delegates are another
major example. I think that scoped delegates avoid the problem, but any that
require closures do not. Other things be done but become risky - e.g. slicing
arrays (the GC normally owns the memory such that all dynamic arrays are
slices and none of them own their memory, so slicing manually managed memory
gets dicey).
There are definitely portions of the standard library that can and should be
useable without the GC, but because some aspects of the language require, some
portions of the standard library will always require it. In general, I don't
think that it's reasonable to expect to use D without a GC. You can really
minimize how much you use it, and if you're really, really careful and avoid
some of D's nicer features, you might be able to avoid it entirely, but
realistically, if you're using D, you're going to be using the GC at least
some.
In general, the trick is going to be allowing custom allocators where it makes
sense (e.g. containers) and being smart about how you design your program
(e.g. using structs instead of classes if you don't need the extra abilities
of a class - such as polymorphism). So, if you're smart, you can be very
efficient with memory usage in D, but unless you really want to hamstring your
usage of D, avoiding the GC entirely just doesn't work.
Note that you can use manual memory management for classes.
