Eliminate class allocators and deallocators?

[dsimcha]

== 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.
> Andrei

Perfect.  I'd be happy with this proposal as long as noone makes it harder to
manually free GC-allocated memory while the GC implementation is still
conservative mark-sweep or something similar.  I had been under the impression
that you wanted to flat-out get rid of GC.free().  Making it implementation
defined but requiring that it at least exist even if it does nothing makes perfect
sense.  If the implementation changes to some better algorithm (not likely in the
short term, but fairly likely in the long run), then my whole rationale for
wanting to free stuff manually in the first place may change.