On Thursday, 27 October 2022 at 17:39:14 UTC, Quirin Schroll wrote:
>On Wednesday, 26 October 2022 at 20:24:38 UTC, tsbockman wrote:
>A @safe
function is guaranteed by the compiler to be memory safe to call from other @safe
code with (almost) any possible arguments and under (almost) any circumstances.
A @trusted
function is guaranteed by its author to be memory safe to call from other @safe
code with (almost) any possible arguments and under (almost) any circumstances.
The “(almost)” should be absent. If you mean something other than compiler bugs, please tell us.
In practice, @safe
code depends upon a guard page to catch null
pointer dereferences. If a struct field or static array element is at a sufficiently large offset from the null
pointer, this can theoretically result in a silent buffer overrun. As far as I can tell, this is not considered a bug, but rather a reasonable trade-off for improved performance.
Also, doing anything at all is officially undefined behavior after a failed assertion. This is, again, theoretically problematic because debug builds may call user code to prepare or log the AssertError
.
There are probably other obscure cases like these, as well, which @safe
and @trusted
functions are not responsible for handling correctly.
I agree with the characterization of @safe
and @system
. For @trusted
functions, there’s something more to say:
...
- Narrowly accessible ones (e.g.
private
(in a small module), local functions, immediately executed lambdas) can have a@system
interface, but their surroundings can be trusted to use the function correctly.
My characterization agrees with the language spec, yours does not. You are essentially redefining @trusted
to mean "ignore memory any memory safety issues here", instead of what it is actually intended to mean, "trust me, this is actually memory safe".