Eliminate class allocators and deallocators?

[downs]

Jeremie Pelletier wrote:
> 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.

Well I certainly wouldn't expect that! :p

This sounds like something that might trip people up. I believe at least scanning objects by GC should always be the default for any object, if only because the association "D heap => GC managed" is I think a fairly core part of the language.