DIP1000 scope inference

tsbockman thomas.bockman at gmail.com
Thu Oct 27 23:30:24 UTC 2022


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](https://dlang.org/spec/expression.html#assert_expressions) 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](https://dlang.org/spec/function.html#trusted-functions), 
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".


More information about the Digitalmars-d mailing list