Eliminate class allocators and deallocators?

[Sean Kelly]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >> dsimcha wrote:
> >>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >>> 2.  Maintaining two separate heaps (the manually memory managed C heap and the
> >>> GC'd D heap) is a massive and completely unacceptable kludge because:
> >> Coding in a way that requires the GC to offer manual deletion is a
> >> completely unacceptable kludge. Most GCs could NOT offer a primitive to
> >> manually release memory. Designing D around a requirement that manual
> >> deletions work on the GC is crippling pressure on GC designers.
> >
> > Ok, fine, you got me on one point:  Manual freeing of objects only makes sense in
> > certain GC implementations.  So what?  GC.free() can be defined by the runtime
> > implementation.  If you're using something like pointer bump allocation with
> > generational, moving GC, the implementation is free to do nothing.  If you're
> > using conservative mark/sweep, it should actually free memory.
> I think there is convergence! My larger point is that we can leave
> GC.free() with loose semantics (e.g. may or may not act on it), and that
> we need to remove class-level allocators and probably the delete keyword
> too.

The docs for GC.free() should already state that what actually happens is
implementation-defined.  If they don't it's an oversight on my part.  I do
agree that the presence of "delete" in D is a bit weird, and would be happy
to see it replaced by a library routine.  new as well.