Accessing memory after destroy

[via Digitalmars-d]

On Sunday, 30 July 2017 at 07:45:27 UTC, Johan Engelen wrote:
> On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis 
> wrote:
>>>
>>> [1] https://dlang.org/spec/class.html#deallocators
>>
>> If destroy has been called on a class object, then it is a bug 
>> to access it at any point after that (IIRC, the expectation is 
>> that it will blow up in your face, because the vtable is gone 
>> - TDPL talks about this, I believe, but I don't know where my 
>> copy is at the moment, so I can't check). That being said, the 
>> memory is still valid. And as Moritz pointed out, if the 
>> memory is accessible, the GC won't free it. So, it's a bug to 
>> access the object, but it should be memory safe to do so.
>
> If this is the case, then we really need to improve and 
> pin-down the spec on this point.
>
> So `destroy` only calls the destructor and puts the object in 
> `T.initializer` (non-constructed) state, and is otherwise not 
> related to memory deallocation.
> May the destructor be called again when the GC collects the 
> memory?
> Why is the object put in `T.initializer` state?

rt_finalize2 zeroes the vptr out after assigning 
typeid(T).initializer, so calling the destructor more than once 
is not possible, unless someone manually saves the vptr and 
assigns it back to the object after the call to destroy / 
rt_finalize.

> To make sure: My question is from a spec point of view. Not 
> about what currently happens and what is "OK" with the current 
> implementation.

I guess the spec needs to be updated to state explicitly that a 
class destructor is called only once, if that's not already the 
case.