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.
