An exegesis of Walter's reference counted slice

[Walter Bright via Digitalmars-d]

On 2/24/2015 2:45 PM, deadalnix wrote:
> Using malloc make the GC blind. It means you can't stored anything GCed in this.

GC.addRange() solves this problem.


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

If cycles are not possible, malloc/free should be used. Cycles are not possible 
in objects without indirections, and we can assert they are not possible it the 
type can be introspected at compile time to see if cycles are not possible.

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

To have an arbitrary sub graph be memory safe with return ref, the interface to 
it will have to be constructed to only allow access by values or return refs.


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

No language offers a way to check system code for safety. Not Java, not Rust, 
not C#, not nobody, not no how. What is offered is safety for the client's usage 
of it. C++ doesn't have that.