On 2014-04-11 06:29:32 +0000, Nick Sabalausky
<[email protected]> 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
[email protected]
http://michelf.ca
