An exegesis of Walter's reference counted slice

[Andrei Alexandrescu via Digitalmars-d]

I modified Walter's sample code to this: 
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array 
and the reference count, and also uses @trusted minimally. I inserted 
assert()s here and there to clarify the workings. Nothing big except for 
the careful use of @trusted.

I'll use this as a basis of some exegesis.

1. The code is a bit more complicated than it should. Overall this is 
not a biggie; regular D users are not supposed to write reference 
counted slices casually. But I was bummed that e.g. I found no way to 
call emplace() @safe-ly.

2. Michel's point (https://issues.dlang.org/show_bug.cgi?id=14221) 
reveals the largest issue with RC/GC integration. We need to find a fix 
for it if we want to have the GC lift cycles.

3. opIndex ("here's the magic") is the most interesting part of the 
proposal. It disallows unsafe use such as:

@safe ref int fun()
{
    auto a = RCArray!int([1, 2, 3]);
    return a[1];
}

Nice. I'd go as far as saying that barring implementation bugs, with 
DIP25 in tow, and after we fix 14221, it's impossible to get an invalid 
memory access with RCArray in @safe code. This (we offer a way to design 
@safe arrays and more generally structs that are @safe) is interesting 
and important.

That said there is a rub. The part that deallocates memory in the 
destructor must be @trusted. That is fine, but the trustworthiness of 
that code depends on the "return" attribute in opIndex. Furthermore, if 
the author of RCSlice forgets to put "return" there, the compiler won't 
help - it just allows wrong code like fun() above to compile and run 
(causing dangling pointer use).

So: does DIP25 allow safe slices? Looks that way, though a proof would 
be nice. Does it allow other safe interesting structs that own data? 
Very likely. Does it allow really sophisticated ownership schemes? We 
need to explore that. Does it protect against bugs in implementations of 
safe ownership schemes that explicitly release memory? Not too well. I 
think the prevalent idiom will be to accompany such artifacts with 
unittests that make sure unsafe uses (such as fun() above) do not compile.


Andrei