Eliminate class allocators and deallocators?

[downs]

Don wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> 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.
>>>>>
>>>>> Andrei
>>>> So you can still deallocate a class by hand, only it's not called
>>>> delete anymore?
>>> That is correct.
>>>
>>> Andrei
>>
>> Isn't that a pretty big violation of Least Surprise?
>>
>> http://en.wikipedia.org/wiki/Principle_of_least_astonishment :
>> "In user interface design, programming language design, and
>> ergonomics, the principle (or rule or law) of least astonishment (or
>> surprise) states that, when two elements of an interface conflict, or
>> are ambiguous, the behaviour should be that which will *least
>> surprise* the human user or programmer at the time the conflict arises."
> 
> I think the basic rule being introduced is:
> that every object can be managed by the gc, or manually managed. But not
> both. That seems reasonable to me. But if delete no longer deletes, it
> needs a name change.


Oh, that makes more sense.

Do manually managed objects still count under Mark&Sweep?