Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Jeremie Pelletier wrote:
> Andrei Alexandrescu 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 wouldn't like delete to go away at all, I use it for all my non-gc 
> objects like this watered down example:
> 
> class ManualObject : Object {
>     new(size_t size) { return malloc(size); }
>     delete(void* mem) { free(mem); }
> }
> 
> And then I can easily subclass it for any objects that doesn't need the 
> GC. I've got similar constructs for arrays and structs.

Clearly you use those objects in a very different manner than GC 
objects. So by using new/delete with them you're fooling yourself.

// untested
class ManualObject {
     static T create(T : ManualObject)() {
         auto p = malloc(__traits(classInstanceSize, T));
         memcpy(p, T.classinfo.init.ptr, __traits(classInstanceSize, T));
         auto result = cast(T) p;
         result.__ctor();
         return result;
     }
     static void yank(ManualObject obj) {
         free(cast(void*) obj);
     }
}

Looks like a fair amount of work? At some level it actually should, but 
we can put that kind of stuff in the standard library.

> malloc/free are nice, but they don't allow for elegant abstractions like 
> new/delete does (for example if you want to use a specialized non-gc 
> allocator you can just replace a few calls instead of every allocation).

They do if you're willing to write just a bit of scaffolding.

> I also use delete when I no longer need large blocks of memory, I don't 
> want them to just become uninitialized and sitting on the GC. When I 
> want to do that I just nullify my references.
> 
> If you're afraid of deleting an object that may still have valid 
> references, use smart pointers, or don't delete it at all if it sits on 
> the gc and just call a .destroy() method.
> 
> Also in my runtime the delete implementations do free the memory, they 
> don't just call the finalizer.
> 
> In any ways, just don't remove new/delete overrides from the language 
> please, just call it a low-level technique or something to scare the 
> beginners away and let people who want it have it :)

I strongly believe custom new/delete must go.


Andrei