@trusted assumptions about @safe code

[ag0aep6g]

On 27.05.20 15:43, Paul Backus wrote:
> I think you are focused in so closely on this particular example that 
> you are losing track of the bigger picture.

That's entirely possible.

> Knowing that a function is @safe guarantees you that (modulo errors in 
> @trusted code) it will not violate memory safety when called with safe 
> arguments. That is the *only* thing @safe guarantees.

Agreed. The question is: What else can @trusted code rely on, beyond the 
guarantees of @safe?

[...]
> In the case of strlen, you can rely on the wording of 
> the C standard which states that "The strlen function returns the number 
> of characters that precede the terminating null character" to know that 
> if you call it with a null-terminated string (its precondition), the 
> result will be in-bounds (its postcondition).

Ok. An @trusted function can rely on the C standard. I take it that an 
@trusted function can also rely on other documentation of @system 
functions. So far I'm with you.

 From your previous post I figured that this is your position towards 
calling @safe from @trusted:

     @trusted code is not allowed to rely on the documented
     return value of an @safe function. The @trusted function
     must instead verify that the actually returned value is
     safe to use.

I'm not sure if I'm representing you correctly, but that position makes 
sense to me. At the same time, it doesn't seem feasible, because I don't 
see how we're going to get users to adhere to that.

The way I see it we can either make the rules for @trusted so arcane 
that practically no one will be able to follow them, or we accept that a 
change in @safe code can lead to memory corruption. At the moment I'm 
leaning towards the latter.