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