The "@safe vs struct destructor" dilemma
Nick Sabalausky
SeeWebsiteToContactMe at semitwist.com
Thu Apr 10 23:29:32 PDT 2014
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?
More information about the Digitalmars-d
mailing list