std.allocator needs your help

[Bigsandwich]

Hi,

I mostly just lurk around here, but occasionally I just can't 
resist putting in my two cents.  I really want to see D replace 
C++ for AAA games (my industry) and allocators are really 
critical to that.  I think there's an elephant here that most of 
the posts have been dancing around.

In C++ when you roll your own allocators (whether STL allocators 
or some other interface) there is basically, only one set of 
*semantics* to worry about - the classic C++/C pattern of 
new/delete or malloc/free.  This is actually much more 
complicated in D where you have at least two different semantics:

1) C++/C style
2) Tracing/Garbage Collection
3) Region allocators and other oddballs

Consequences:
1) These semantics aren't really interchangeable.  If, for 
instance, a library is implemented with one of them in mind, it 
can only be replaced by an allocator with the same semantics.

2) Tracing/Garbage Collection are required for whatever the 
default allocator is and replacement allocator must implement 
those semantics.

3) Its only possible to change (2) by hacking the runtime so that 
any language features that rely on the GC cause errors.

The design Andrei has presents seems to *allow* the creation of 
allocators with all of these semantics, but it doesn't seem to 
answer the following questions:

1) Can semantics be enforced?
2) Can allocators with different semantics be composed?
3) Can different semantics for the default allocator be 
implemented?
4) If so, how can I reconcile that with libraries that expect 
different default semantics?  A use case that I foresee for 
something like this would be banning the use of GC in low level 
engine code, but allowing it in higher level gameplay code.

5) Are any of these questions even relevant for this part of the 
design or will we have to wait for the rest of it to know the 
answers?

Thanks.