An important pull request: accessing shared affix for immutable data

[Andrei Alexandrescu via Digitalmars-d]

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