An exegesis of Walter's reference counted slice

[Ivan Timokhin via Digitalmars-d]

Andrei Alexandrescu wrote:

> 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

Is there any plan to allow safe conversions to T[] (in restricted 
circumstances, of course)?