Simplification of @trusted

[Dukc]

On Thursday, 17 June 2021 at 17:24:27 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 17 June 2021 at 15:08:53 UTC, Dukc wrote:
>> No language can do this. C++ API does not provide any safety 
>> guarantees, so calling a C++ function means that it needs to 
>> be manually verified, or it's authors trusted, BY DEFINITION.
>
> Sure, but that is obviously not enough. Because what is being 
> said implies that @trusted code have to assume that anything it 
> receives that isn't pointers can be garbage and that such 
> garbage should never lead to memory unsafety even if _you know_ 
> that the @trusted function never receives garbage.

Ah, I guess the problem is that someone phrased that slightly 
wrong. Let me try a better formulation.

Given a module `module_a`, if a client module `module_b` that 
imports only `module_b`, and contains only `@safe` code cannot 
cause memory corruption (except due to compiler/OS/hardware 
bugs), then and only then API of `module_a` is sound with regards 
to memory safety.

This means that a `@trusted` or `@safe` function is allowed to 
assume certain invariants about some types, as long as those 
invariants cannot be violated from `@safe` client code alone. 
This also means that `@safe` code that is in `module_a` may be 
able to violate memory safety. DIP1035 aims to address that.