Memory safety depends entirely on GC ?

[deadalnix via Digitalmars-d]

On Sunday, 22 February 2015 at 17:01:45 UTC, Andrei Alexandrescu 
wrote:
> 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.
>

What ??? That mean writing all library code twice, for client 
that want GC and for these who don't. That is a looser strategy.

> 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.
>

Sounds like a world class RC would not force all the code to be 
written twice.

> 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.
>

I don't think we want to implement RC in the language, but 
implement what would allow to have safe RC as library.