== Quote from Andrei Alexandrescu ([email protected])'s article > downs wrote: > > Andrei Alexandrescu wrote: > >> Hello, > >> > >> > >> D currently allows defining class allocators and deallocators. They have > >> a number of problems that make them unsuitable for D 2.0. The most > >> obvious issue is that D 2.0 will _not_ conflate destruction with > >> deallocation anymore: invoking delete against an object will call > >> ~this() against it but will not recycle its memory. In contrast, class > >> deallocators are designed around the idea that invoking delete calls the > >> destructor and also deallocates memory. > >> > >> So I'm thinking of removing at least class deallocators from the > >> language. Class allocators may be marginally and occasionally useful if > >> the user takes the matter of deallocation in her own hands. > >> > >> A much better way to handle custom allocation of classes would be in the > >> standard library. > >> > >> What do you think? > >> > >> > >> Andrei > > > > Do you trust the D GC to be good enough to always free everything you've > > allocated, without error? > > > > If your answer was 'ye- maaybe ... no actually', please rethink this. > People will always be able to call functions in the garbage collector > manually. The discussion on class allocators and deallocators has > nothing to do with that.
Right. There's no plan to eliminate GC.free().
