Memory safety depends entirely on GC ?

[via Digitalmars-d]

On Monday, 23 February 2015 at 15:35:52 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 23 February 2015 at 14:56:11 UTC, Marc Schütz wrote:
>> violation of the principle of separation of concerns: a 
>> consumer shouldn't need to have information about the 
>> management strategy, it should work equally with 
>> `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it 
>> doesn't take ownership of the resource.
>
> Just be aware that by not making the refcount part of C you 
> either:
>
> 1. Need one more indirection.
>
> 2. Need a more complicated allocator to avoid alignment padding 
> when C has 32byte/64 byte alignment requirements.
>
> 3. Risk having the refcount landing on a different cacheline, 
> causing more cache misses.
>

The refcount would be embedded right next to the object by the 
constructor of `RefCounted!C`, which is responsible for 
allocating memory for it, using an appropriate allocator.

> If you do excessive refcounting (ARC) and care about 
> performance you actually need to let the implementor of C 
> decide where the RC_counter is embedded...

Of course there can be an additional (template) parameter to 
`RefCounted`, or it could be a different, user-implemented type 
altogether.

But my point was that all of `Unique!C`, `RefCounted!C` and `C` 
should decay to `scope C`. This way, most consumers don't need to 
be aware of the actual wrapper type (if any) at all.