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. 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. - Jonathan M Davis