draft proposal for ref counting in D

[Walter Bright]

Michel Fortin wrote:

Le 27-juin-2013 à 15:32, Walter Bright  a écrit :

 > On 6/27/2013 11:38 AM, Michel Fortin wrote:
 >>> 14. RC objects will still be allocated on the GC heap - this means that a 
normal
 >>> GC run will reap RC objects that are in a cycle, and RC objects will get 
automatically
 >>> scanned for heap references with no additional action required by the user.
 >> If you allocate the object from the GC heap, the GC will collect it 
regardless of its reference count. That's fine as long as all the retaining 
pointers are visible to the GC. But if you're defining a COM object, likely 
that's because you'll pass a pointer to an external API, and this API might 
store the pointer somewhere not scanned by the GC. This API will call AddRef to 
make sure the object is retained, but if the GC doesn't see that pointer on its 
heap it'll deallocate and next time external code uses the object everything 
goes boom! So that doesn't work.
 >
 > We already require that if you're going to pass a pointer to any GC allocated 
data to external code, that you retain a pointer. I see no additional issue with 
requiring this for COM objects created on the GC heap.


Perhaps it's just me, but I'd say if you need to anticipate the duration for 
which you need to keep the object alive when you pass it to some external code 
it completely defeats the purpose of said external code calling AddRef and Release.

With the scheme you propose, reference counting would be useful inside D code as 
a way to deallocate some classes of objects early without waiting a GC scan. The 
GC can collect cycles for those objects.

People passing COM objects to external code however should allocate those 
objects outside of the GC if they intend to pass the object to external code. 
They should also add member pointers as GC roots. Also, no cycle detection for 
those objects. If done right it could be made memory safe, but cycles will leak.

Maybe that could work.