On 29.05.19 18:37, Valeriy Fedotov wrote:
> In my point of view @trusted means "I use pointer-related operations correctly. Also I am using all @system interfaces correctly".

@trusted means: "This function is as safe as an @safe function. But the compiler doesn't verify the implementation." Whether you use anything correctly only matters when it affects safety.

And "being safe" means that the function doesn't exhibit undefined behavior (when called with valid inputs), and that it doesn't lead to undefined behavior in @safe code that is executed later on (e.g., an @trusted function must not return an invalid pointer).

[...]
> If a user supplies mallocator that is not correct, there are two possibilities:
> 
> - Allocator is buggy. Nothing to do with @trusted code.
> - Allocator do not conforms to allocator interface. User has broken the contract. Nothing to do with @trusted code.

In my example, UnsafeAllocator is correct. It's not buggy, and it conforms to the allocator interface (which doesn't require @safe methods). Still the program exhibits memory corruption. So there must be something else that's wrong.

The problem is that I'm setting UnsafeAllocator.instance.i to bad values which leads to out-of-bounds accesses. I do that in the @safe `main`. You might say: "Don't do that then. It's your own fault if you do that. Your mistake is not the library's fault."

But D's @safe is supposed catch exactly that kind of mistake. The point of @safe is that I can make all the mistakes in the world in @safe code (except typing out "@trusted") without ever seeing memory corruption.

> I think we should keep in mind not only technical aspects of @trusted and @system, but this contract too.

No. A contract that can be broken in @safe code cannot be relied upon in @trusted code. This is fundamental to D's safety system.