RCArray is unsafe

[Andrei Alexandrescu via Digitalmars-d]

On 3/2/15 2:57 PM, Walter Bright wrote:
> On 3/2/2015 1:09 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>"
> wrote:
>> "I have discovered a marvellous solution, but this post is too short
>> to describe
>> it."
>
> Fortunately, Fermat (er, Andrei) was able to pass along his dazz idea to
> me this afternoon, before he expired to something he had to attend to.
> We were both in the dumps about this problem last night, but I think he
> solved it.
>
> His insight was that the deletion of the payload occurred before the end
> of the lifetime of the RC object, and that this was the source of the
> problem. If the deletion of the payload occurs during the destructor
> call, rather than the postblit, then although the ref count of the
> payload goes to zero, it doesn't actually get deleted.
>
> I.e. the postblit manipulates the ref count, but does NOT do payload
> deletions. The destructor checks the ref count, if it is zero, THEN it
> does the payload deletion.
>
> Pretty dazz idea, dontcha think? And DIP25 still stands unscathed :-)
>
> Unless, of course, we missed something obvious.

And since an RCArray may undergo several assignments during its lifetime 
(thus potentially needing to free several chunks of memory), the arrays 
to be destroyed will be kept in a freelist-style structure. Destructor 
walks the freelist and frees the chunks.

Andrei