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.
