std.allocator ready for some abuse

[Chad Joan]

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu 
wrote:
> Hello,
>
>
> ... awesome stuff ...
>
> Please destroy! I've literally sweat as I'm sending this :o).
>
>
> Andrei

I like it a lot so far.

I was really worried about being able to dynamically dispatch to 
an allocator determined at a previous place in the call stack, 
and it seems you're all over it with CAllocator.  Hell yeah!

I have an editing suggestion for the CAllocator comment:
Instead of
"Implementation of CAllocator using Allocator. [...]"
I suggest
"Implements CAllocator using the given Allocator. [...]"
The current one read strangely to me at first, and I had to 
re-read it several times and notice that "Allocator" referred to 
the template parameter.

I agree with others that say that the name CAllocator is too 
ambiguous or vague.  When I scanned through the allocators, I 
initially dismissed it because I though it was a proxy for the 
system's underlying C allocator, with Mallocator being a D-based 
optimized reimplementation of the C allocator.  Reading further 
clarified this, but it does probably harm skimming and searching.

I suggest an alternative name for CAllocator: 
DispatchingAllocator.  I believe this may represent what it does: 
dispatch allocation to another allocator that is behind a 
curtain.  Something like AbstractAllocator might work too, but 
still seems slightly ambiguous to me (i.e. abstract in what 
sense?).

I just hope that the future "top" allocator that handles 
language-builtin allocations will be one that can maintain a 
stack of allocators and push/pop the current default allocator, 
as well as prevent or redirect allocator choice made within calls 
to 3rd party libraries (assuming the libraries are written in D, 
of course).