Eliminate class allocators and deallocators?

[Jeremie Pelletier]

downs wrote:
> 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?

You have to register the memory range they cover to the GC if they 
contain pointers to GC memory. Otherwise the GC don't know they exist at 
all.