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.
