Accessing memory after destroy

[Steven Schveighoffer via Digitalmars-d]

On 7/30/17 9:17 AM, Petar Kirov [ZombineDev] wrote:
> 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.

Yes, this is on purpose. It's the way the runtime knows it has already 
been run. In fact, destroy used to NOT do this, and that caused problems.

A class instance is not usable after calling destroy. It is not intended 
to be usable, because classes require a constructor call to be valid, 
and there's no way to guarantee you can do this with destroy.

Structs are different.

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

I thought this was in the spec, but I can't find it. This is definitely 
the case.

-Steve