More radical ideas about gc and reference counting

[Michel Fortin via Digitalmars-d]

On 2014-05-11 19:37:30 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 5/11/2014 5:52 AM, Michel Fortin wrote:
>> On 2014-05-11 08:29:13 +0000, Walter Bright <newshound2 at digitalmars.com> 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
michel.fortin at michelf.ca
http://michelf.ca