[Dlang-study] Safe Memory Management and Ownership.

[xray]

Hi there,

I have been through the discussions on the forum regarding scope, 
ownership, GC and so on.  After a serious thought about this, I'd 
like to discuss about a possible solution for this matter. My 
concern is to know if my solution could work and to discuss the 
possible impact on the current D language.


After watching the Dconf 2018 session about "Safe Memory 
Management", I told myself that, if D can guarantee an exception 
in the case we delete an already deleted object, then it's a 
major step forward. So let's assume that.

Now, let's distinguish two kind of references, one being "owner" 
of the object it targets, and other that are smooth references to 
the same object.

We could say that a given object will always belong to one and 
only one owner. This owner will be in charge of deleting the 
object.

There will be 2 cases. If the owner is a local variable, as soon 
as the variable is out of scope, the object is deleted. If the 
owner is an attribute of a extra object, the deletion happens 
after the extra object is deleted.

The syntax could look like it (don't pay much attention to the 
key word I use, it's only to illustrate).


void main()
{
    auto r := new Rectangle(5,6); // r owns the object.
    auto r4 := new Rectangle(8,7); // r4 owns the object.
    auto f = new Foo();

    // now r2 owns the object. Deletion still happens when r2 is 
out of scope.
    auto r2 := r;

    auto r3 = r2; // Smooth reference

    // fonction1 only borrow the object, so it will not delete it.
    fct1( r2 );

    auto rr := f.fct2( in r2 );

    // We can STILL use r3 at our own risk (we don't know the r2's 
destiny).
    // Considering the design and UT will prevent bugs.

    auto w = r3.getWidth(); // An exception is raised if r3 is not 
valid.

    f.fct3( in r2 ); // Compilation error, we cannot give what we 
no longer own.

    f.fct3( in rr ); // Ok.

    // implicit code :
    // delete r4;
    // delete f , then f deletes rr by owership.
}

class Foo
{
    Rectangle my_r;

    out Rectangle fct2( in Rectangle r )
    {
        return out r;
    }

    fct3( in Rectangle r )
    {
       this.my_r := r; // Foo is the owner of r now.
    }

}

This way, all the libraries would explicitly tell where the 
memory is managed. All classes could keep their attribute objects 
under management if they are designed to.

I cannot see a case where we could miss a memory deallocation 
because the compiler will add the delete for us at the expected 
spot.

Of course, we can easily run into invalid smooth references (kind 
of NPE). But if D provides safe memory management, well, we can 
handle it.

Tell me guys what you think :)