d future or plans for d3

Jonathan M Davis jmdavisProg at gmx.com
Tue Dec 20 02:48:22 PST 2011


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


More information about the Digitalmars-d mailing list