@trusted assumptions about @safe code

[Paul Backus]

On Tuesday, 26 May 2020 at 00:01:37 UTC, ag0aep6g wrote:
> 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.

There's no part of the program outside of f's body that has 
access to either reference while both are alive, so I'd say 
that's fine.

In Rust-ish terms, the ownership of the array is being moved from 
a to the return value, whereas in the previous example, both f 
and g were attempting to mutably borrow the same data at the same 
time.