@trusted assumptions about @safe code

[Paul Backus]

On Wednesday, 27 May 2020 at 06:36:14 UTC, ag0aep6g wrote:
> I.e., "the exact behavior of @safe functions (including their 
> return values) cannot be relied upon for safety". I think it's 
> going to be hard selling that to users. Especially, because 
> there is no such requirement when calling @system functions.

I think you are focused in so closely on this particular example 
that you are losing track of the bigger picture.

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.

If you want to guarantee anything else about what the function 
does, there are many tools you can use to do so. You can use in 
and out contracts to establish preconditions and postconditions. 
You can use assert or enforce in calling code to check that the 
arguments and/or return value meet some criteria. You can have it 
accept or return types with invariants. 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).

There's nothing weird or unusual or "a hard sell" about this. 
Programming is always like this, in any language, memory-safe or 
not.