ref is unsafe

[comco]

On Friday, 4 January 2013 at 20:20:08 UTC, Jonathan M Davis wrote:
> On Friday, January 04, 2013 17:26:59 Zach the Mystic wrote:
>> > Honestly though, I'm inclined to argue that functions which
>> > return by ref and
>> > have a ref parameter of that same type just be considered
>> > @system.
>> 
>> Structs mess that up as well:
>> struct S { int i; }
>> ref int d(ref S s)
>> {
>> return s.i;
>> }
>
> Yes. That's a function which takes a ref and returns by ref 
> just like I said.
> It's just that in this case, the ref returned isn't the full 
> object that was
> passed by ref but just a portion of it. What that means is that 
> you can't
> assume that the ref being returned is safe just because the 
> type of the
> parameter and the return type aren't the same. But it doesn't 
> change the
> statement that a function which takes a parameter by ref and 
> returns by ref
> can't be considered @safe without additional constraints of 
> some kind. It just
> shows why you don't have an easy way out to make many of them 
> @safe based on
> the differing types involved.
>
> - Jonathan M Davis

Why this won't work?
1. If the function code is available at ct, we can check for 
escaping locals.
2. Otherwise, we want to statically say to the compiler that the 
returned ref is safe exactly in these lines in which the 
particular function argument, from which the ref has been 
extracted, has not yet gone out of scope. So the returned ref 
safety guarantee tracks the argument safety guarantee.
Something like this:

ref int f(@infer_safe_from ref int a);

With such an annotation on an argument, the compiler will be able 
to infer the safety of a function when used in cases in which a 
is in scope whenever the returned ref is referenced.

Now, if f is used in this manner:
{