Simplification of @trusted

[Mathias LANG]

On Thursday, 17 June 2021 at 12:52:40 UTC, Ola Fosheim Grøstad 
wrote:
> It can't call free, but since the language does not have a full 
> blown borrow checker or isolated ownership pointer types, there 
> is also no way anyone can be 100% certain (as in provably 
> correct code).

Wat ? That doesn't make any sense. A function that would free its 
input *has to be @system*.

> My take on this is that interfacing with C/C++ undermines @safe 
> to such an extent that C/C++ interop isn't really as big of a 
> selling point as it is made out to be (meaning you have to 
> choose either @safe or C/C++ interop). I think that is a 
> problem. If you have two big features then you shouldn't have 
> to choose. The conception of @safe has to work well for people 
> who write large application with lots of C/C++ interop.

C++ interop is what convinced my company to use D in the first 
place. You're right that those two features have friction, but I 
take C/C++ interop over `@safe` any day of the week.

> But it does not guarantee anything about the content that is 
> being pointed to. That will trip most interesting use cases for 
> unsafe code. Just think about an array with memory-offsets.

Anything that deals with an array of memory offset needs to be 
encapsulated in its own data structure. `@safe` is about exposing 
a `@safe` interface, that is, something that can't be misused. If 
you use an array of memory offsets, then you have to do pointer 
arithmetic, which is not `@safe`.

> That definition makes @trusted mostly useless as @safe code can 
> clearly change those memory-offsets. That prevents interesting 
> high performance ADTs from being @safe, even when they are 
> correctly implemented. You actually should think of the the 
> whole class as @trusted then.

You *can't* mark a function as trusted if it accepts an array of 
memory offset and just uses it. And you can't call that 
"correctly implemented", either.