> What in my eyes looks wrong is the fact that destroy is invoked for the > parent whenever the x.parent.children.delete(pos) is invoked, although it is > already nil. Tried what I could to inhibit with .nodestroy - no success (v > 1.5.1 orc/arc with/without --experimental).
Perhaps I understand what might be occurring.. Many destroy's will include a `nil` check first thing. The compiler doesn't know at compile time if a given object is destroyed already, so anytime you do the `.destroy` or `obj = nil` it can invoke the destroyer. So while doing the semi-manual memory management can be done ... it's tricky! Also, since a non-ref object lives on the stack, in theory you can call `destroy=` on it any number of times since you can't `free` the memory. Normally ARC will only call it once, but if you're overriding the `destroy=` then you have to put quite a bit of thought into manually calling the destroys, etc. Personally I only use destroy'ers on ref types to free C structs that were manually allocated by C-libs. Even then I'd prefer not to do it. > Valid comment ... Considering the above even more ... Thanks I've actually learned a bit here too. It's a good way to dive in.. but probably better to use built-in tools and let the compiler deal with it as @araq mentioned. ;-) If you're wanting to do "high-performance" memory (like for a game engine) then there's good options like [weave](https://forum.nim-lang.org/t/6713). Though I'd recommend the simpler seq[RefSomeObj] until you have an explicit need. The Nim compiler and std-lib do pretty well. Perhaps you might sprinkle in some `move` annotations or profile the ref-vs-value types. Happy Nim'ing!
