On 2/22/15 6:49 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schue...@gmx.net>"
wrote:
No. There's also returning the reference from a member function, storing
it in a passed-in reference (pointer, ref, out or slice), and passing it
to other functions that in turn leak the reference, as well as throwing
it. And leaking closures containing the reference.
That's all that I can think of now...
Consider
class C { ... client code ... }
alias T = RefCounted!C;
... more client code ...
For reference counting to work transparently, access to the symbol "C"
must be restricted. RefCounted obviously needs access to it. Client code
should never have access to it, even in the definition of C.
That means:
1. client code must not be able to declare variables of type C or issue
calls like "new C" etc.
2. The type of "this" in methods of C must be RefCounted!C, not C.
3. Conversions of C to bases of C and interfaces must be forbidden; only
their RefCounted!Base versions must be allowed.
4. Returning references to direct members of C must be restricted the
same way they are for structs (see http://wiki.dlang.org/DIP25). A GC
class object does not have that restriction.
I think reference counting is an important component of a complete
solution to resource management. D should implement world-class
reference counting for safe code.
For 1-4 above, although I am a staunch supporter of library-exclusive
abstractions, I have reached the conclusion there is no way to implement
RC in safe code for D classes without changes to the language. The more
we realize that as a community the quicker we can move to effect it.
Andrei
