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