@safe leak fix?

[BCS]

Hello Walter,

> 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.
> 

Sounds good. If it happens, I'd vote for a push on the static analysis to 
do those proofs.