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.
