std.allocator needs your help

[deadalnix]

On Tuesday, 24 September 2013 at 18:53:56 UTC, Bigsandwich wrote:
> 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.

I'd like to see these question answered. This is one of the most 
insightful posts of the discussion.