Memory safety depends entirely on GC ?

[Andrei Alexandrescu via Digitalmars-d]

On 2/22/15 6:49 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at 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