Eliminate class allocators and deallocators?

[Sean Kelly]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'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().