On 02/12/2016 08:24 PM, Dicebot wrote:
- considering this API is going to be dangerously @system, possible corruption of metadata is indeed very scary - though not a blocker within my own value list
I don't think this is an argument worth minding, either.
- I wonder if would make for a cleaner design to have distinct allocator instances for thread-local and shared memory instead of branching on qualifiers of requested type
TypedAllocator does exactly that. Not difficult to integrate here, but the key here is removing immutability without subverting the type system (which is a distinct matter).
Right now the main concern to me is how such design is going to interact with existing code like `assumeUnique`. With GC which treats all memory similarly it is legal (and somewhat common) to allocate mutable non-shared data first and only later cook it into immutable via `assumeUnique`. But if allocator has to treat such memory differently (i.e. add barriers/atomics for non-TLS one) such code will start silently introduce major bugs.
Folks who defined refcounted types use the special AffixAllocator internally in an encapsulated manner. They define it, they use it - outside intervention is not possible. Those who use their own allocation calls and then use assumeUnique cannot use it on the new types. Or maybe I'm not understanding something.
Andrei