On 2014-05-11 19:37:30 +0000, Walter Bright <[email protected]> said:
On 5/11/2014 5:52 AM, Michel Fortin wrote:
On 2014-05-11 08:29:13 +0000, Walter Bright <[email protected]> said:
Again, O-C and C++/CX ARC are not memory safe because in order to make it
perform they provide unsafe escapes from it.
But D could provide memory-safe escapes. If we keep the current GC to collect
cycles, we could also allow raw pointers managed by the GC alongside ARC.
Let's say we have two kinds of pointers: rc+gc pointers (the default) and
gc_only pointers (on demand). When assigning from a rc+gc pointer to a gc_only
pointer, the compiler emits code that disables destruction via the reference
counting. This makes the GC solely responsible for destructing and deallocating
that memory block. You can still assign the pointer to a rc+gc pointer
later on,
but the reference count is no longer reliable which is why RC-based destruction
has been disabled.
Yes, you can make it memory safe by introducing another pointer type,
as Rust does. But see my comments about this scheme in the message you
replied to.
(Yes, I understand your proposal is a variation on that scheme.)
It is a variation on that scheme, but with one significant difference:
those two pointer types can mix and there's no restriction on
assignments from one type to the other. There's therefore no transitive
effect and no complicated ownership rule to understand.
This obviously does not address all your concerns with ARC (which I'll
admit most are valid), but this "ARC isn't memory-safe" argument has to
stop. It does not make sense. One doesn't need to sacrifice memory
safety to use ARC, neither is that sacrifice necessary for having
islands of non-ARC code. That's what I was trying to point out in my
previous post.
--
Michel Fortin
[email protected]
http://michelf.ca
