RFC: moving forward with @nogc Phobos

[via Digitalmars-d]

On Wednesday, 1 October 2014 at 09:52:46 UTC, Andrei Alexandrescu 
wrote:
> On 9/30/14, 12:10 PM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>> I would argue that GC is at its core _only_ a memory management
>> strategy. It just so happens that the one in D's runtime also 
>> comes with
>> an allocator, with which it is tightly integrated. In theory, 
>> a GC can
>> work with any (and multiple) allocators, and you could of 
>> course also
>> call GC.free() manually, because, as you say, management and 
>> allocation
>> are entirely distinct topics.
>
> I'm not very sure. A GC might need to interoperate closely with 
> the allocator. -- Andrei

It needs to know what to scan (ideally with type info), and which 
allocator to release memory with, but it doesn't need to be an 
allocator itself. It certainly helps with the implementation, but 
ideally there would be a well defined interface between 
allocators and GCs, so that both can be plugged in as desired, 
even with multiple GCs in parallel.