draft proposal for ref counting in D

[Walter Bright]

On 6/27/2013 1:15 PM, 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.
 >

Nothing about the proposal acts to prevent one from constructing COM objects any 
way they wish, including using malloc/free and managing it all themselves. All 
COM objects require is an implementation of the COM interface, which says 
nothing at all beyond having a pointer to an AddRef() and Release().

If you are building a COM object that is to be fired and forgotten into the void 
of unknown external code, I don't think there's any automated replacement for 
thinking carefully about it and constructing it accordingly. D's memory safety 
guarantees cannot, of course, cover unknown and unknowable external code.

What I'm trying to accomplish with this proposal is:

1. A way to do ref-counted memory allocation for specific objects
2. Do it in a guaranteed memory safe manner (at least for the user of those objects)
3. Do it in a way that does not interfere with people who want to use the GC or 
do manual memory management
4. Not impose penalties on non-refcounted code
5. Do it in a way that offers a similar performance and overhead profile to 
C++'s shared_ptr<T>
6. Do it in a way that makes it usable to construct COM objects, and work with 
NSObject's
7. Not require pointer annotations
8. Address the most common "why I can't use D" complaint

What I'm not trying to accomplish is:

1. Replacing all memory allocation in D with ref counting