RCArray is unsafe

[deadalnix via Digitalmars-d]

On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic wrote:
> That's fine. I like DIP25. It's a start towards stronger safety 
> guarantees. While I'm pretty sure the runtime costs of my 
> proposal are lower than yours, they do require compiler 
> hacking, which means they can wait.

I don't think that it is fine.

At this point we need to :
  - Not free anything as long as something is alive.
  - Can't recycle memory.
  - Keep track of allocated chunk to be able to free them (ie 
implementing malloc on top of malloc).

It means that RC is attached to an ever growing arena. Code that 
would manipulate RCArray and append to it on a regular manner 
must expect some impressive memory consumption.

Even if we manage to do this in phobos (I'm sure we can) it is 
pretty much guaranteed at this point that noone else will, at 
least safely. The benefit is reduced because of the bookeeping 
that need to be done for memory to be freed in addition to 
reference count themselves.

The #1 argument for DIP25 compared to alternative proposal was 
its simplicity. I assume at this point that we have empirical 
evidence that this is NOT the case.