== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > dsimcha wrote: > > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > >> dsimcha wrote: > >>> == Quote from Andrei Alexandrescu (seewebsiteforem...@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.