DIP1000 scope inference

[Quirin Schroll]

On Wednesday, 26 October 2022 at 20:24:38 UTC, tsbockman wrote:
> On Wednesday, 26 October 2022 at 10:43:11 UTC, German Diago 
> wrote:
>> Is not trusted code (note my little D experience so sorry if I 
>> am asking something relatively stupid) unsafe? I mean, @safe 
>> is safe, @trusted is ??, @system is you go your own.
>>
>> - So what are the guarantees of @trusted compared to @system?
>
> 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.

> A `@system` function may require the caller to follow 
> additional rules beyond those enforced by the compiler, even in 
> `@safe` code, to maintain memory safety. Since the compiler 
> does not know what these additional rules are and cannot 
> enforce them automatically, calling `@system` functions 
> directly from `@safe` code is forbidden.
>
> | Attribute  | Must check definition | Must check each caller |
> |------------|-----------------------|------------------------|
> | `@safe`    | compiler              | compiler               |
> | `@trusted` | programmer            | compiler               |
> | `@system`  | programmer            | programmer             |
>
> Assume the function is implemented correctly, then try to 
> figure out how to call the function from `@safe` code in a way 
> that violates memory safety. If there is a way to do so, the 
> function should be `@system`.
>
> Otherwise, it should be `@safe` if that compiles, or `@trusted` 
> if not.

I agree with the characterization of `@safe` and `@system`. For 
`@trusted` functions, there’s something more to say:
* Widely accessible ones (e.g. `public`, `package`, `protected`, 
even `private` in a big module) should have a `@safe` interface, 
i.e. you can use them like `@safe` functions in all regards; they 
just aren’t `@safe` because of some implementation details.
* 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.