Simplification of @trusted
Paul Backus
snarwin at gmail.com
Wed Jun 16 16:11:46 UTC 2021
On Wednesday, 16 June 2021 at 14:57:19 UTC, GrimMaple wrote:
> I don't like that this allows implicitly lowering the safety
> level of any given function. As per example, the foo() function
> isn't @safe anymore, but @trusted. Which in turn should be
> reflected in the function signature. If this function is marked
> as @safe, I expect it to be @safe and not perform any shady
> stuff inside it. To me this really looks like foo() should be
> @trusted instead.
There is no difference (from the caller's point of view) between
the "safety level" of a @safe function and a @trusted function.
Both are memory-safe. The only difference is that the @safe
function has its safety checked automatically, by the compiler,
and the @trusted function has its safety checked manually, by the
programmer.
"But surely," you will object, "automatic checking is more
reliable than manual checking, and therefore the @safe function
is 'safer' than the @trusted one." Unfortunately, the conclusion
does not follow from the premise: a @safe function is allowed to
call any number of @trusted functions internally, so it is
entirely possible that *both* functions rely on manual checking
for their memory safety. You cannot tell just from looking at the
signatures.
More information about the Digitalmars-d
mailing list