The "@safe vs struct destructor" dilemma

[Nick Sabalausky]

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?