Eliminate class allocators and deallocators?

downs default_357-line at yahoo.de
Wed Oct 7 00:24:56 PDT 2009


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."



More information about the Digitalmars-d mailing list