Safety, undefined behavior, @safe, @trusted

[Walter Bright]

Steven Schveighoffer wrote:
> On Thu, 05 Nov 2009 17:49:33 -0500, Walter Bright 
> <newshound1 at digitalmars.com> wrote:
> 
>> Jason House wrote:
>>> I posted in the other thread how casting to immutable/shared can be
>>> just as bad. A leaked reference prior to casting to immutable/shared
>>> is in effect the same as casting away shared. No matter how you mix
>>> thread local and shared, or mutable and immutable, you still have the
>>> same undefined behavior
>>
>> Not undefined, it's just that the compiler can't prove it's defined 
>> behavior. Hence, such code would go into a trusted function.
> 
> But how does such a trusted function guarantee that the invariant/shared 
> reference has no other aliases?

It doesn't. Trusted code is verified by the programmer, not the compiler.


> The point is, there is no way to write 
> such a function in good faith because you can't guarantee it's actually 
> safe, it's still up to the user of the function.  My understanding is 
> that a @trusted function should be provably safe even if the compiler 
> can't prove it.
> 
> -Steve