Disadvantages of ARC

[Adam D. Ruppe]

On Thursday, 6 February 2014 at 19:33:39 UTC, Andrei Alexandrescu 
wrote:
> So if T is int[] and you have taken a slice into it...?

If you escape it, congratulations, you have a memory safety bug. 
Have fun tracking it down.

You could also offer refcounted slicing, of course (wrapping the 
Unique thing in a refcounter would work), or you could be 
converted to the church of scope where the compiler will help you 
catch these bugs without run time cost.

> I'm not sure I understand what you are talking about.

When the reference count reaches zero, what happens? This changes 
based on the allocation method: you might call GC.free, you might 
call free(), you might do nothing, The destructor needs to know, 
otherwise the refcounting achieves exactly nothing! We can encode 
this in the type or use a function pointer for it.

struct RefCounted(T) {
     private struct Impl {
         // potential double indirection lol
         private T payload;
         private size_t count;
         private void function(T) free;
         T getPayload() { return payload; } // so it is an lvalue
         alias getPayload this;
     }
     Impl* impl;
     alias impl this;
     this(T t, void function(T) free) {
        impl = new Impl; // some kind allocation at startup lol
                         // naturally, this could also be malloc
                         // or take a generic allocator form the 
user
                         // but refcounted definitely needs some 
pointer love
        impl.payload = t;
        impl.count = 1;
        impl.free = free; // gotta store this so we can free later
     }
     this(this) {
        impl.count++;
     }
     ~this() {
        impl.count--;
        if(impl.count == 0) {
            // how do we know how to free it?
            impl.free(impl.payload);

            // delete impl; GC.free(impl) 
core.stdc.stdlib.free(impl);
            // whatever
            impl = null;
        }
     }
}


In this example, we take the reference we're counting in the 
constructor... which means it is already allocated. So logically, 
the user code should tell it how to deallocate it too. We can't 
just call a global free, we take a pointer instead.


So this would work kinda like this:

import core.stdc.stdlib;
int[] stuff = malloc(int.sizeof * 5)[0 .. 5];
auto counted = RefCounted!(int[])(stuff, (int[] stuff) { 
free(stuff.ptr); });



The allocator is not encoded in the type, but ref counted does 
need to know what happens when the final reference is gone. It 
takes a function pointer from the user for that.


This is a generically refcounting type. It isn't maximally 
efficient but it also works with arbitrary inputs allocated by 
any means.

Unique!T could do something similar, but unique would disable its 
postblit instead of incrementing a refcount.