Eliminate class allocators and deallocators?

[Jeremie Pelletier]

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.