Eliminate class allocators and deallocators?

[Denis Koroskin]

On Tue, 06 Oct 2009 20:01:01 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Hello,
>
>
> D currently allows defining class allocators and deallocators. They have  
> a number of problems that make them unsuitable for D 2.0. The most  
> obvious issue is that D 2.0 will _not_ conflate destruction with  
> deallocation anymore: invoking delete against an object will call  
> ~this() against it but will not recycle its memory. In contrast, class  
> deallocators are designed around the idea that invoking delete calls the  
> destructor and also deallocates memory.
>
> So I'm thinking of removing at least class deallocators from the  
> language. Class allocators may be marginally and occasionally useful if  
> the user takes the matter of deallocation in her own hands.
>
> A much better way to handle custom allocation of classes would be in the  
> standard library.
>
> What do you think?
>
>
> Andrei

I think it's okay, but I have a few points to discuss:

- Is it worth a keyword (delete) just as a shortcut for obj.__dtor();?

- I believe __ctor and __dtor (and __traits, too) are ugly reserved  
identifiers.

- It's often useful to distinguish between dtor being called by user and a  
dtor being called by a GC.
    In the latter case you can't dereference any reference since they might  
be invalid.

- How about object.d provides an IDisposable (or something like this)  
interface which defines a void dispose(bool finalizing); and we get rid of  
~this/__dtor entirely?

- obj.__ctor() is mostly used as a placement new. A new placement new  
mechanism would allow drop that identifier, too.

- D has 2 placement new mechanisms for a struct, that are absolutely the  
same (but different in syntax):

> Foo foo1 = void;
> Foo foo2 = void;

> foo1 = Foo();	   // indirect
> foo2.__ctor();	  // direct

The latter one could also be used for class initialization, but not the  
former one.
You once announced an idea of dropping the 'new' keyword altogether and  
make the former case also valid for classes. What's about it now?

- Could you elaborate on "a much better way to handle custom allocation of  
classes ... in the standard library"? An example would be very appreciated.