why allocators are not discussed here

[cybervadim]

On Wednesday, 26 June 2013 at 14:26:03 UTC, H. S. Teoh wrote:
> Yeah, I think the best approach would be one that doesn't 
> require
> changing a whole mass of code to support. Also, one that 
> doesn't require
> language changes would be far more likely to be accepted, as 
> the core D
> devs are leery of adding yet more complications to the language.
>
> That's why I proposed that gc_alloc and gc_free be made into
> thread-global function pointers, that can be swapped with a 
> custom
> allocator's version. This doesn't have to be visible to user 
> code; it
> can just be an implementation detail in std.allocator, for 
> example. It
> allows us to implement custom allocators across a block of code 
> that
> doesn't know (and doesn't need to know) what allocator will be 
> used.
>

Yes, being able to change gc_alloc, gc_free would do the work. If 
runtime  remembers the stack of gc_alloc/gc_free functions like 
pushd, popd, that would simplify its usage.
I think this is a very nice and simple solution to the problem.