@safe leak fix?

[Steven Schveighoffer]

On Wed, 11 Nov 2009 16:47:10 -0500, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Consider the code:
>
>    @safe:
>      T[] foo(T[] a) { return a; }
>
>      T[] bar()
>      {
>          T[10] x;
>          return foo(x);
>      }
>
> Now we've got an escaping reference to bar's stack. This is not memory  
> safe. But giving up slices is a heavy burden.
>
> So it occurred to me that the same solution for closures can be used  
> here. If the address is taken of a stack variable in a safe function,  
> that variable is instead allocated on the heap. If a more advanced  
> compiler could prove that the address does not escape, it could be put  
> back on the stack.
>
> The code will be a little slower, but it will be memory safe. This  
> change wouldn't be done in trusted or unsafe functions.

This sounds acceptable to me.  In response to others making claims about  
modifying behavior, you can get a safe function that can use unsafe  
behavior by using @trusted if you wish.

I'm assuming this behavior translates to local non-array variables?

Can we allow the scope variable hack that is afforded for delegates:

@safe int sum(scope int[] a) { int retval = 0; foreach(i; a) retval += i;  
return retval;}

This would not result in a heap allocation when called with a static array.

-Steve