My Reference Safety System (DIP???)

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 2 13:41:50 PST 2015


On Monday, 2 March 2015 at 20:04:49 UTC, deadalnix wrote:
> I let the night go over that one. Here is what I think is the 
> best road forward :
>  - triggering postblit and/or ref count bump/decrease is 
> prohibited on borrowed.
>  - Acquiring and releasing ownership does.
>
> Now that we have this, let's get back to the exemple :
> class C {
>     C c;
>
>     // Make ti refconted somehow, doesn't matter. Andrei's 
> proposal for instance.
> }
>
> void boom() {
>     C c = new C();
>     c.c = new C();
>
>     foo(c, c.c);
> }
>
> void foo(ref C c1, ref C c2) {
>     // Here is where things get different. c1 is borrowed, so 
> you can't
>     // do c1.c = null before acquiring c1.c beforehand.

Right, I agree with this.

> That means the
>     // compiler needs to get a local copy of c1.c, bump the 
> refcount
>     // to get ownership before executing c1.c = null and 
> decrease
>     // the refcount.

Yeah, but should it do this inside foo() or in bump() right 
before it calls foo. I think in bump, and only for a parameter 
which might be aliased by another parameter (an extremely rare 
case). For any other case, the refcount has already been 
preserved:

void boom() {
     C c = new C(); // refcount(c) == 1
     c.c = new C(); // refcount(c.c) == 1
     auto d = c.c; // refcount(c.c) == 2 now
     foo(c, d); // safe
}

The only problem is the rare case when the exact same identifier 
is getting sent to two different parameters.

I'm sure there will be opportunities to elide a lot of refcount 
calls, but in this case,  I don't see much to left to elide.


More information about the Digitalmars-d mailing list