Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

[Andrei Alexandrescu]

Hi all,


Eduard, Alexandru Jercaianu and I are working on improving allocators' 
design and implementation. This entails a few breaking changes.

In order to make matters easier for code using allocators, Sebastian 
Wilzbach created a dub package freezing the existing API: 
http://code.dlang.org/packages/stdx-allocator. Please use that until we 
work the kinks out of allocators - great things are coming! - and after 
that feel free to upgrade code to use the new and improved allocators.

One rather disruptive piece we're working on is converting IAllocator 
from an interface to a reference counted structs (that in turn uses an 
interface internally). This is so there is deterministic control of how 
many users a given allocator has, so it can be destroyed deterministically.

Another possible work item was raised by 
https://github.com/dlang/phobos/pull/5879. Currently, allocators traffic 
in void[]. When I first designed allocators, I considered using ubyte[] 
instead. Using void[] is somewhat closer to the intent of allocators - 
that memory is meant to be used for storing anything. However, using 
void[] makes it difficult to express the fact that allocate() is a safe 
function for virtual all allocators. So we may switch to ubyte[] to 
express that at the lowest level we're trafficking chunks of octets. 
This is not a big design change, but it's bound to break code.


Thanks,

Andrei