An exegesis of Walter's reference counted slice

[deadalnix via Digitalmars-d]

On Tuesday, 24 February 2015 at 19:40:35 UTC, 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.
>

Using malloc make the GC blind. It means you can't stored 
anything GCed in this. Which means you either need to enforce 
this at the interface level (I have no idea how) or remove all 
these @trusted in the code.

Generally using malloc is not the right way forward. I do think 
that, even for RCed resource, we want them backed by the GC. It 
will allow for cycle collection. The main problem with the GC is 
not allocation, it is collection, and collection won't fire if 
one do not leak.

> 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.
>

There is a set of feature that create implicit sharing. GC is 
only one of them. They either need to be fixed (and here, you'll 
get my point about simple fix aggregating to something more 
complex) or make this thread safe.

> 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.

As long as you don't plan to own an arbitrary sub graph.

> Does it allow really sophisticated ownership schemes? We need 
> to explore that.

Limited, unless you wrap all indirection in some sort of struct 
down the road.

> 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.
>

I though we wanted to do better than C++...