@trusted assumptions about @safe code

[ag0aep6g]

On 26.05.20 01:25, Paul Backus wrote:
> My reading of the spec is that f violates this requirement of safe 
> interfaces:
> 
>> 3. it cannot introduce unsafe aliasing that is accessible from other 
>> parts of the program.
> 
> "Other parts of the program," taken at face value, should include both 
> f's callers (direct and indirect) as well as any functions it calls 
> (directly or indirectly). Since f introduces unsafe aliasing, and makes 
> that aliasing visible to g, it should not be marked as @trusted.
> 
> I suppose it depends on exactly what is meant by "accessible"--if it 
> refers to the aliased memory location, then my interpretation follows, 
> but if it refers to the pointers, there's an argument to be made that f 
> is fine, since only one of the pointers escapes.

Hm. The meaning I intended with that is that it's only invalid when the 
memory location becomes accessible via both types elsewhere. And g only 
has access via one type.

Would you say that this next function is also leaking unsafe aliasing?

     immutable(int[]) f() @trusted
     {
         int[] a = [1, 2, 3];
         a[] += 10;
         return cast(immutable) a;
     }

Because that one is definitely supposed to be allowed.

And I must also say that I didn't really consider called functions to be 
"other parts of the program". But reading it that way makes sense. Then 
I suppose calling an @safe function with both ends of an unsafe aliasing 
can be seen as already not allowed.