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.
