eliminate new operator paraphernalia

[Andrei Alexandrescu]

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:hl9n50$2f9v$1 at digitalmars.com...
>> There are many problems with custom allocators. They hook the syntax and 
>> do something that's unbecoming. new T must place T on the 
>> garbage-collected heap, period. That gives the guarantee that the object 
>> has infinite lifetime and therefore dependable behavior. If the same 
>> syntax can be used to implement various other semantics, you can't count 
>> on anything in generic code.
>>
> 
> Sounds to me like the exact same argument for eliminating operator 
> overloading: "If we allow it, then someone could hijack '+' to do something 
> unbecoming and then you can't count on anything in generic code". Generic 
> code (at least in D) naturally comes with a risk of duckiness.

It's not the same argument, but I can't afford the time to debate that.

> The whole point of custom allocators is to allow something to get the same 
> result (get a new instance) through a different implementation.  And as for
> the infinite lifetime guarantee: I don't think I see any risk of a 
> custom-allocated object getting yanked out from under generic code unless 
> you did something *really* bizarre and obviouly pointless like lauch a 
> thread that randomly marks elements in an object pool as unused. 

My point is that custom new is not transparent at all. One typical 
example of class-specific new and delete is using malloc as a backend. 
So then you have some types for which you need to pair new and delete, 
and some for which you don't. Not good.

All that's needed is the ability to create an object at a given address, 
and the ability to destroy a given object. This is what the language 
must provide. All the rest can and should be built via regular facilities.


Andrei