The "@safe vs struct destructor" dilemma

[Marc Schütz" <schuetzm at gmx.net>]

On Saturday, 12 April 2014 at 03:02:56 UTC, Michel Fortin wrote:
> 1- make the GC call the destructor in the same thread the 
> object was created in (for non-shared objects), so any access 
> to thread-local stuff stays in the right thread, avoiding 
> low-level races.

There also needs to be a mechanism to promote a local object to 
shared (and probably vice versa). This can be easily done with 
unique objects, although depending on the implementation, it 
would require moving memory.

>
> 2- after the destructor is run on an object, wipe out the 
> memory block with zeros. This way if another to-be-destructed 
> object has a pointer to it, at worse it'll dereference a null 
> pointer. With this you might get a sporadic crash when it 
> happens, but that's better than memory corruption. You only 
> need to do this when allocated on the GC heap, and only 
> pointers need to be zeroed, and only if another object being 
> destroyed is still pointing to this object, and perhaps only do 
> it for @safe destructors.

More correctly, every reference to the destroyed object needs to 
be wiped, not the object itself. But this requires a fully 
precise GC.