D's Destructors are What Scott Meyers Warned Us About

[12345swordy]

On Wednesday, 23 May 2018 at 18:11:45 UTC, Jonathan M Davis wrote:
> On Wednesday, May 23, 2018 18:04:28 12345swordy via 
> Digitalmars-d wrote:
>> On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis 
>> wrote:
>> > On Wednesday, May 23, 2018 17:29:11 12345swordy via
>> >
>> > Digitalmars-d wrote:
>> >> [...]
>> >
>> > Regardless of what issues destroy may currently have, the 
>> > entire reason that it exists is to destroy objects - and 
>> > class objects in particular. So, if it doesn't currently 
>> > work properly for that purpose, it needs to be fixed.
>> >
>> > - Jonathan M Davis
>>
>> Here is the thing though, when you call destroy on the object, 
>> you would assume by the name that the memory occupied by it 
>> will be deallocated which is NOT always the case. At this 
>> point I rather rename it as .deint, as it is less misleading 
>> here.
>
> The documentation is quite clear that it does not free the 
> memory, and it's never been the case that it was supposed to. 
> And we already renamed it once from clear because of the 
> problems that it caused with containers. At this point, I think 
> that it would be overkill to rename it yet again, especially 
> since we've been trying to not rename stuff unless we really 
> need to, because it causes code breakage for what it usually 
> minimal benefit.
>
> - Jonathan M Davis

My point being is that current objects rely on the external 
finalize function for de-inialtalzation, which is not ideal if 
you wanted to call destroy in the scope of system default 
attributes like @safe or @nogc. How do you think that the 
finalize function should behave in these contexts?