Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Jeremie Pelletier wrote:
> Sean Kelly wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s 
>> article
>>> downs 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
>>>> Do you trust the D GC to be good enough to always free everything 
>>>> you've allocated, without error?
>>>>
>>>> If your answer was 'ye- maaybe ... no actually', please rethink this.
>>> People will always be able to call functions in the garbage collector
>>> manually. The discussion on class allocators and deallocators has
>>> nothing to do with that.
>>
>> Right.  There's no plan to eliminate GC.free().
> 
> But that's runtime dependent, for example on my runtime its 
> Memory.Free(). Removing 'delete' would therefore bind the code to a 
> certain runtime, that's not a very portable solution, and far from being 
> as elegant as delete.

There's nothing elegant about delete.

Andrei