Memory safety depends entirely on GC ?

[Andrei Alexandrescu via Digitalmars-d]

On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> 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.

That's not feasible. Code that assumes the class object will live 
forever can simply do things that are not allowed to code that must 
assume the object will go away at some determined point. Consider this 
which I just posted:

class Widget
{
     private char name[1024];
     char[] getName() { return name[]; }
     ...
}

The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT know whether 
getName() is okay or not.

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

Well I don't know of another way.

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

So what do you propose instead? I am well aware of the disadvantages of 
a solution that _works_. Do you have something better?

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

Structs and slices can be implemented @safe-ly after the advent of 
DIP25. It's classes that are the troublemaker.

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

That does awfully little to help. I'm telling things as they are. It's 
difficult to disagree with e.g. "a refcounted class cannot be implicitly 
convertible to Object and stay refcounted".

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

Looking forward to your insights.


Andrei