Safe reference counting cannot be implemented as a library

[Paulo Pinto via Digitalmars-d]

On Wednesday, 28 October 2015 at 03:55:25 UTC, deadalnix wrote:
> On Wednesday, 28 October 2015 at 01:13:16 UTC, Walter Bright 
> wrote:
>>
>> It's not just safety. If the compiler knows that reference 
>> counting is going on, it can potentially elide a lot of the 
>> overhead. If it is faced with an arbitrary library solution, 
>> it only has a worm's eye view of it, and cannot do higher 
>> level optimizations.
>
> I don't think the compiler can do that much more, but before I 
> address that point, let me mention that intrinsic can be added 
> for inc and dec, which would be much more lightweight for the 
> language at large.
>
> Now as to why I think this wouldn't give that much. First, if 
> exception can be thrown, then all bets are pretty much off, as 
> inc and dec do not go by pairs anymore. So we are down to the 
> no exception situation. In that case, pairs are fairly visible 
> to the compiler and can be optimized away or combined, that is 
> already the kind of things that optimizer are good at.
>
> But if, so, how do you explain the C++ situation, where nothing 
> is elided (or ObjC's) ?
>
> Well, there is a major difference with these languages: sharing 
> by default. It means that inc and dec must be (atomic and 
> ordered) or synchronized, which means that, as far as the 
> compiler is concerned, all bets are off and the optimizer can't 
> do its job.
>
> This doesn't really apply to D, so I don't expect this to be a 
> problem. And even if there is: intrinsic can save the day to 
> hint the optimizer, no need for heavyweight language addition.
>
> Now, let's get back to the exception case, as it is IMO the 
> most interesting one. What if one is willing to accept leakage 
> on exception throwing. That would get the optimizer back into 
> the game and remove a lot of "dark matter" as Andrei calls it, 
> which have a real cost on term of icache pressure and exception 
> unwinding cost (one now doesn't have to resume each frame to 
> maintain refcount).
>
> If I had to go about this, I'd rather see the introduction a 
> scope(exit/success/failure) like mechanism for destructors 
> rather than something ref counting specific.

Objective-C  does elide refcounting, there are a few WWDC ARC 
sessions where it is mentioned. Same applies to Swift.

However their exceptions work in a more RC friendly way.