In general, of course, this is a bad idea - there's probably a reason that destructor does the thing it's doing. If you're sure skipping it is what you want, go ahead.
@Biotronic, the code you have provided may be exactly what I am looking for. Let me explain my situation.
I have a library that has been ported from a C/C++ code. A struct Bar that is part of the library implements its own refcounted GC. The refcounted GC of course works via constructor and destructor. But this refcounted GC also uses some thread local variables since there is a need to implement parallelism.
It all works well so far. But as soon as I create an instance of Bar inside a Dlang class (say Foo) or as part of a Dlang dynamic array, hell follows. At some point, Dlang's GC kicks in and Bar's destructor gets called from within Dlang's GC. Now since Dlang executes GC on a different thread, the destructor gets confused and segfaults. Fortunately for me, it would be fine if the call to destructor is completely avoided within the realm of Dlang's GC since I do not need the Bar instances thereafter. All I need to do is to dismantle Bar completely from the memory to avoid leaks. So long as I can avoid calls to Bar's destructor from within Dlang's GC, I am fine.
I also have some limitations. Since we need to run all this on an embedded system with limited RAM (and given that I have millions of instances of Bar which is only 32-bit wide), I do not want to add a flag or other stuff to Bar. And that is the reason we are using thread local storage in the refcounted GC.
So there. I will try your way. Let me see if I can make it to work in my situation. Thanks for sharing.
