draft proposal for ref counting in D

Walter Bright newshound2 at digitalmars.com
Wed Oct 9 17:09:04 PDT 2013


Michel Fortin wrote:

Le 25-juin-2013 à 17:20, Steven Schveighoffer a écrit :

 > On Jun 25, 2013, at 4:44 PM, Walter Bright wrote:
 >
 >> On 6/25/2013 1:19 PM, Steven Schveighoffer wrote:
 >>>
 >>> Would this be a mechanism that's worth putting in? I think it goes really 
well with something like TempAlloc.  I don't think we should use convention, 
though...
 >>
 >> I agree with not relying on convention. But also reserving the new*, init*, 
alloc* and copy* namespaces seems excessive for D.
 >>
 >> As for autoreleasepool, it is relying on a convention that its fields are 
not leaking. I don't see how we can enforce this.
 >
 > I don't think the autoreleasepool is relying on convention, it's simply 
giving the compiler a way to elide careful tracking of temporaries' reference 
counts.

Not at all. Autorelease pools were useful at a time before ARC so you wouldn't 
have to think of releasing manually every object called functions were returned 
to you. Instead, most functions would return autoreleased object and you'd only 
have to retain those objects you were storing elsewhere.

Nowadays, with ARC, we still have them but that's mostly for interoperability 
already existing code. Most functions still return autoreleased objects because 
that's the convention, and breaking that convention would cause objects to be 
retained or released to many times. So we still need autorelease pools. But ARC 
is hard at work[^1] behind the scene to reduce the number of those autoreleased 
objects.

So no, we shouldn't introduce autorelease pools to D... well, except maybe for 
the part were we want interoperability with Objective-C (because we have no choice).

And finally, there's nothing unsafe with autorelease pools as long as you don't 
keep an unretained reference to an autoreleased object when the pool drains. 
Making sure you have no unretained reference is ARC's job, so with ARC it should 
not be no problem.

[^1]: One clever trick ARC does is inside the implicit call to 
objc_returnAutoreleased it adds at the end of an autoreleasing function, the 
runtime checks to see if the return address points to an instruction that'll 
call objc_retain on that same pointer. If that's the case, it skips the 
autorelease and also skip objc_retain and goes to the next instruction directly. 
Of course if the convention was always to return object retained, none of this 
would be needed. I saw that explained on a WWDC video a couple of years back.



More information about the Digitalmars-d mailing list