Memory safety depends entirely on GC ?

[via Digitalmars-d]

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

No, this would require the class to be specialized for 
refcounting. But the memory management method needs to be the 
client code's decision; it can decide to manage some instance by 
refcounting, some by Unique!C, and leave others to the GC. The 
class implementer shouldn't need to care about all that.

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

These two points have undesirable consequences: All consumers 
such objects need to be aware of the exact type, which includes 
the management strategy (RC, Unique, GC). But this is a violation 
of the principle of separation of concerns: a consumer shouldn't 
need to have information about the management strategy, it should 
work equally with `RefCounted!C`, `Unique!C` and bare (GC) `C`, 
as long as it doesn't take ownership of the resource.

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

This is only a partial solution that doesn't work efficiently 
with anything other then value members. Slices, pointers and 
classes require introducing an additional, useless indirection, 
and that's not the only problem with it.

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

I'm not sure this is what you're implying, but do you want to 
restrict it to classes only? Why not structs and slices, too?

Of course I agree that a language change is necessary, but I'm 
convinced what you suggest above is not the right direction at 
all. (And I see that deadalnix has already replied and basically 
said the same thing.)

In general, this and related proposals tend to limit themselves 
on memory management (as witnessed by the importance that `ref` 
and `@safe` play in them). This is too narrow IMO. A well 
thought-out solution can be equally applicable to the broader 
field of resource management.