Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de octubre a las 14:16 me escribiste:
>> Sean Kelly wrote:
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>>> dsimcha wrote:
>>>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>>>>> It is a bad idea because distinguishing between release of (expensive)
>>>>>> resources from dangerous memory recycling is the correct way to obtain
>>>>>> deterministic resource management within the confines of safety.
>>>>> This is based on two faulty assumptions:
>>>>>
>>>>> 1.  Memory is cheap.  (Not if you are working with absurd amounts of data).
>>>>> 2.  Garbage collection is never a major bottleneck.  (Sometimes it's a worthwhile
>>>>> tradeoff to add a few manual delete statements to code and sacrifice some safety
>>>>> for making the GC run less often.)
>>>> malloc.
>>> So for placement construction of a class, I guess it would look something like:
>>>
>>> auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
>>> x.__ctor( a, b, c ); // construct
>>> ...
>>> x.__dtor();
>>> free( cast(void*) x );
>>>
>>> Is that right?
>> Yes, I think so, but I haven't checked all the details. For example
>> I'm not sure whether __ctor copies .init over the memory before
>> running the user-defined constructor, or expects that to have been
>> done already.
>>
>> My understanding from Walter is that __ctor(x, y, z) are simply the
>> functions this(x, y, z) as written by the user, so you'd need to
>> memcpy the .init by hand before calling __ctor.
> 
> What I don't understand is why you're willing to make that hard to do
> manual memory management in D. Do you see that you're making the
> programmer's job deliberately for no reason? D needs conservative GC,
> which means slow GC; by definition. D is a system programming language, so
> it's expected to be fast, but because of the GC there will be often
> situations where you have to do manual MM. Why are you making that much
> harder?
> 
> You know that in the search for safety you'll be making much more unsafe
> (or bug-prone) to do manual MM?

You seem to be asserting that without additional built-in language 
support, manual memory management is unduly difficult. Why so?

Andrei