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