| |
![xray's Gravatar profile Gravatar of xray](//www.gravatar.com/avatar/9d939963df6dc4d4f5c69b4911e1eae4?d=identicon&s=32) | Posted by xray | Permalink Reply |
|
xray ![xray's Gravatar profile Gravatar of xray](//www.gravatar.com/avatar/9d939963df6dc4d4f5c69b4911e1eae4?d=identicon&s=80)
| 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 :)
_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
|