An exegesis of Walter's reference counted slice

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 24 16:41:45 PST 2015


On Wednesday, 25 February 2015 at 00:11:28 UTC, Walter Bright 
wrote:
>> 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.
>

Why ? There is very little chance that malloc + GC.addRange 
becomes any faster that GC.malloc in the first place.

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

That means all library code must be duplicated. I could explain 
you why this is bad, but someone already made a very good point 
about it there: 
http://www.drdobbs.com/cpp/type-qualifiers-and-wild-cards/231902461

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

A language is an API to the system you are running on. A very 
expressive and complex one, but an API nevertheless.

A good API will make correct and safe use easy and incorrect and 
unsafe use convoluted, so they are done on purpose and not by 
mistake.

That is not about proving system code correct (impossible) that 
is about making unprovable code harder to spit out than provable 
one (or getting an error).


More information about the Digitalmars-d mailing list