Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

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