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