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