@safe leak fix?

[Steven Schveighoffer]

On Thu, 12 Nov 2009 08:45:36 -0500, Jason House  
<jason.james.house at gmail.com> wrote:

> Walter Bright Wrote:
>
>> Jason House wrote:
>> > At a fundamental level, safety isn't about pointers or references to
>> > stack variables, but rather preventing their escape beyond function
>> > scope. Scope parameters could be very useful. Scope delegates were
>> > introduced for a similar reason.
>>
>> The problem is, they aren't so easy to prove correct.
>
> I understand the general problem with escape analysis, but I've always  
> thought of scope input as meaning @noescape. That should lead to easy  
> proofs. If my @noescape input (or slice of an array on the stack) is  
> passed to a function without @noescape, it's a compile error. That  
> reduces escape analysis to local verification.

The problem is cases like this:

char[] foo()
{
   char buf[100];
   // fill buf
   return strstr(buf, "hi").dup;
}

This function is completely safe, but without full escape analysis the  
compiler can't tell.  The problem is, you don't know how the outputs of a  
function are connected to its inputs.  strstr cannot have its parameters  
marked as scope because it returns them.

Scope parameters draw a rather conservative line in the sand, and while I  
think it's a good optimization we can get right now, it's not going to  
help in every case.  I'm perfectly fine with @safe being conservative and  
@trusted not, at least the power is still there if you need it.

-Steve