std.allocator needs your help

[qznc]

On Monday, 23 September 2013 at 07:31:46 UTC, Jacob Carlborg 
wrote:
> On 2013-09-23 01:49, Andrei Alexandrescu wrote:
>
>> I am making good progress on the design of std.allocator, and 
>> I am
>> optimistic about the way it turns out. D's introspection 
>> capabilities
>> really shine through, and in places the design does feel really
>> archetypal - e.g. "this is the essence of a freelist 
>> allocator". It's a
>> very good feeling. The overall inspiration comes from Berger's
>> HeapLayers, but D's introspection takes that pattern to a 
>> whole new level.
>
> I agree with Manu here. I thought the whole point was to come 
> up with a design and API how the allocators are supposed to be 
> used. How they integrate with user code.
>
> Here's a quick idea:
>
> I can think of at least four different usage patterns how an 
> allocator can be set. Hopefully this will be backwards 
> compatible as well.
>
> 1. Globally - The same allocator is used in the whole 
> application by all threads
>
> 2. Thread local - The allocator is set per thread. Different 
> threads can used different allocators
>
> 3. Function local - This is the most intrusive. Sets the 
> allocator for a given function call
>
> 4. Block local - The allocator is used during a given block

5. Class local - The allocator is used for specific types (e.g. 
ASTNode in a compiler)

6. Class-hierarchy - The allocator is used for a specific type 
hierarchy (e.g. ASTNode might have sub classes 
Statement,BinOp,etc)

7. Container local - The C++ way which binds allocation to a 
wrapping container

8. Task local - like Thread local but for std.parallelism.Task

That's it for now.

This is quite a long list, which means it is probably exhaustive. 
There should be a generic approach which encompasses at least 
those cases.