GC blessed for C++ (again)

[Jack Stouffer via Digitalmars-d-announce]

On Tuesday, 11 April 2017 at 16:50:20 UTC, jmh530 wrote:
> Is there a non-breaking way to do it that would increase the 
> amount of flexibility while keeping the current behavior as a 
> default? For instance, the equivalent of using 
> std.experimental.allocator so that a user could switch between 
> the default being GCAllocator or Mallocator, or something like 
> that...

 From what I understand, the plan has always been to start to 
integrate std.experimental.allocator into Phobos when it 
stabilizes. There are some questions though:

1. How is this going to be done? Do we have the functions in 
Phobos allocate with theAllocator? Or, do we pass in an allocator 
type via template parameter? Or, do we pass in an allocator 
instance via function parameter? Each solution has it's own pros 
and cons.

2. How do you make it @safe? For the GC allocator, you can make 
allocation @safe, but not deallocation. So do you special case 
GCAllocator in Phobos code to not call GCAllocator.deallocate() 
and just let the GC collect?

3. How will @safe ref-counting play in with this? Andrei has his 
sights set on putting all strings in their own ref-counted store 
in order to make them @safe @nogc. Is RC going to be it's own 
allocator?

I've never seen comprehensive plans or ideas about allocator 
integration. I've heard rumblings about a collections library 
that supposed to use it, but never seen anything.