On Tuesday, 16 June 2015 at 16:28:54 UTC, Etienne wrote:
On Tuesday, 16 June 2015 at 15:39:06 UTC, rsw0x wrote:
destructors as they are shouldn't exist at all, they are
incredibly bug prone.
Bye.
To be fair, everything is bug prone until you understand them.
No, they are just bug prone.
GC finalization is done in a single lock, none of the memory is
re-used, so objects can have their own "destroyed" flags and
destroy eachother fine if the typeinfo issue isn't there.
Implementation-defined behavior.
On the other hand, by keeping the GC destructors, we must agree
that all the destructors are declared this way:
shared @nogc nothrow ~this()
Only then can we count it in as having predictable behavior.
Still not predictable, as they can be ran in any thread, in any
order, and be ran parallel.
I can't really agree on removing finalizers, I'd really love to
master GC destructors in D so that I can return plain class
objects from my functions with data allocated elsewhere, like
in any managed language out there. It's really the only way.
Don't get me wrong, I allocate and free on a freelist or pool
everywhere I can, but the GC has its advantages and I'd really
like to put it to work (safely) to build more convenient APIs.
You're attempting to use GC for a problem that they don't solve
because you don't have other tools to fix it. When all you have
is a hammer, everything looks like a nail.
