The "@safe vs struct destructor" dilemma

[Michel Fortin]

On 2014-04-11 06:29:32 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe at semitwist.com> said:

> So the idea behind @safe is most code should be @safe, with occasional 
> @system/@trusted pieces isolated deeper in the call chain. That 
> inevitably means occasionally invoking @system from @safe via an 
> @trusted intermediary.
> 
> Realistically, I would imagine this @trusted part should *always* be a 
> dummy wrapper over a specific @system function. Why? Because @trusted 
> disables ALL of @safe's extra safety checks. Therefore, restricting 
> usage of @trusted to ONLY be dummy wrappers over the specific parts 
> which MUST be  @system will minimize the amount of collateral code that 
> must loose all of @safe's special safety checks.
> 
> This means some mildly-annoying boilerplate at all the @safe -> @system 
> seams, but it's doable...*EXCEPT*, afaics, for struct destructors. 
> Maybe I'm missing something, but I'm not aware of any reasonable way to 
> stuff those behind an @trusted wrapper (or even an ugly way, for that 
> matter).
> 
> If there really *isn't* a reasonable way to wrap @system struct 
> destructors (ex: RefCounted) inside an @trusted wall, then any such 
> structs will poison all functions which touch them into being @trusted, 
> thus destroying the @safe safety checks for the *entire* body of such 
> functions. Well, that is, aside from any portions of the function which 
> don't touch the struct *and* can be factored out into separate @safe 
> helper functions - but that solution seems both limited and 
> contortion-prone.
> 
> Any thoughts?

Can destructors be @safe at all? When called from the GC the destructor 
1) likely runs in a different thread and 2) can potentially access 
other destructed objects, those objects might contain pointers to 
deallocated memory if their destructor manually freed a memory block.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca