RCArray is unsafe

[Zach the Mystic via Digitalmars-d]

On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu 
wrote:
> On 3/3/15 9:00 AM, Zach the Mystic wrote:
>> On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu 
>> wrote:
>>>> I was dazzed, but I'm not anymore. I wrote my concern here:
>>>>
>>>> http://forum.dlang.org/post/ylpaqhnuiczfgfpqjuww@forum.dlang.org
>>>
>>> There's a misunderstanding here. The object being assigned 
>>> keeps a
>>> trailing list of past values and defers their deallocation to
>>> destruction. -- Andrei
>>
>> So you need an extra pointer per instance?
>
> Yah, or define your type to be single-assignment (probably an 
> emerging idiom). You can massage the extra pointer with other 
> data thus reducing its cost.
>
>> Isn't that a big price to
>> pay? Is the only problem we're still trying to solve aliasing 
>> which is
>> not recognized as such and therefore doesn't bump the 
>> refcounter like it
>> should? An extra pointer would be overkill for that. Isn't it 
>> better to
>> just recognize the aliasing when it happens?
>
> It's all tradeoffs. This has runtime overhead.

Isn't allocating and collecting a freelist also overhead?

> A static analysis would have the challenges of being permissive 
> enough, cheap enough, not add notational overhead, etc. etc.

It's certainly permissive: you can do anything, and compiler 
wraps uncertain operations with add/release cycles automatically. 
These are: passing a global as a mutable reference to an impure 
function; aliasing the same variable in two parameters with 
itself. The unoptimized lowerings would be:

{
   auto tmp = myGlobal; // bump count
   impureFun(myGlobal);
}  // tmp destroyed, --count

{
   auto tmp2 = c; // bump count
   fun(c, c);
} // --count

The only addition is an optimization where the compiler elides 
the assignments and calls the add/release cycles directly.