std.allocator ready for some abuse

[Joseph Rushton Wakeling]

On 25/10/13 11:37, Namespace wrote:
> We would have then the possibility to manage our memory by ourself. One of D's
> promises is, that the GC can be disabled. Yes, it can, but then we have many
> many things which do not work. For example built-in arrays. With the ability of
> allocators the promise could come true.

That's something I'd really like to know more about.

My D code almost invariably works with the "natural" way to handle memory in D, 
which is to use "new" where needed, plus stuff like array appending ~ and 
alterations to array lengths, with all allocations handled behind the scenes by 
the GC.  I've always felt bad about the fact that this therefore imposes use of 
the GC on anyone who uses my code.  It would be great if one could just write 
idiomatic D code and know that others using it could dictate different 
memory-management strategies and have them "just work".