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.
