I've argued elsewhere some things that are wrong with RAII and C++ objects in general.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?
I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).
You keep "asking" for evidence but the only evidence presented by yourself is that you have merely surface-level understanding of the subject matter, and are looking for arguments, not insight and critical examination.
It's your claim that destructors are harmful so the burden of proof is on you.
People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate, which require no explicit cleanup once the destructor is implemented.
This is the opposite of C where even though the resource cleanup needs to happen on scope end, it is not automatic, and so becomes a source of bugs. This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
This automation also removes boilerplate so there is less management that needs to be done when using data structures.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?