Permalink
Reply
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@systeminterface, 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".
