nogc v0.5.0 - DIP1008 works!

[ag0aep6g]

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.