Bug 8177 – Let the _type_ create the object; don't call _d_newclass directly!

Instead of directly translating the code new MyClass() to (MyClass)_d_newclass(typeof(MyClass)) please translate it to something like MyClass.opNew(typeof(MyClass)) where opNew (or __construct or whatever you will call it) is a static method responsible for creating an instance of the given type (which might be a subclass of the static method's class) on the heap and returning the type, or a pointer to the type in the case of a struct. The default implementation of this method would be VERY simple: it would live inside Object, and forward the request to _d_newclass. Similarly, please modify the GC and the object_.destroy() methods so that they call typeid(typeof(instance)).opDelete(instance), rather than directly deleting the pointer or the object. The default implementation of this method would simply call instance.~this() -- which is also trivial to implement! This would allow D code to perform the constructor/destructor calls __INSIDE__ C callbacks (such as the Windows API), which would allow all kernel handles to be collected by the GC -- something which is otherwise impossible for code that must use callbacks. (For a full explanation of why this feature is necessary, and why it is currently impossible to implement, see this thread: http://forum.dlang.org/post/[email protected] )

Important correction: The default implementation of opNew() MUST do BOTH of these tasks, not just the first one: 1. Call _d_newclass(), to allocate the object 2. Call the constructor, foo.this(), to initialize the object In other words, it would be responsible for _creating a new object, given a type_. It must _NOT_ simply do /one/ of the two above, because C-style callbacks would require that the constructor be called somewhere _inside_ opNew(), not somewhere externally.

Oops, another correction, this time more minor: There should be no 'typeid' for opDelete. It should simply say typeof(instance).opDelete(instance). (The goal here is to avoid virtual dispatch for opDelete() -- if the class designer deems them necessary, he/she can implement the virtual dispatching manually; for the compiler, only the compile-time type of the variable really matters.)

considering that class allocators have been deprecated then removed this ER is not applicable.