draft proposal for ref counting in D

[Walter Bright]

Rainer Schuetze wrote:

On 28.06.2013 22:29, Walter Bright wrote:
 >
 > On 6/28/2013 1:11 PM, Rainer Schuetze wrote:
 >> On 28.06.2013 21:50, Walter Bright wrote:
 >>> The main problem with this is the decay of a shared_ptr!C to a C. Once
 >>> that happens, all the memory safety goes out the window.
 >>
 >> By "decay", do mean the lowering or something else?
 >>
 >> There is no stray C reference in user code, it always gets lowered to
 >> shared_ptr!C. Only @trusted code in shared_ptr will have to deal with
 >> "raw" references. It is shared_ptr's responsibilty to maintain memory
 >> safety, just the same as for AddRef and Release.
 >>
 >
 > "Decay" means it is converted to type C in order to call functions that
 > take C as the 'this' pointer or C as a parameter. The problem is both
 > type C and type shared_ptr!C will exist.
 >

Any parameter of type C is also lowered to shared_ptr!C. Calling a member 
function would go through opDot, which could also do reference counting for 
safety. Treating every explicite or implicite usage of "this" as a temporary 
shared_ptr!C might be overkill, so it could be restricted to assigning "this" to 
another reference (this includes passing it as an argument to another function 
or returning it from a function). My current adhoc rule: if "this" is not 
followed by a '.', it has to be lowered to construct shared_ptr!C(this).

Assuming the reference count is updated by shared_ptr!C.opDot, there will always 
be a thread local reference while inside a member function (it must have been 
called through an external reference at least once). Other member functions of 
the same object can always be called without ref-counting assuming that the 
object never gets destroyed through changing other references.