return by auto ref horribly broken ?

[monarch_dodra]

I think I'm opening a can of worms here, in regards to inferring 
the escape of references, but a quick investigation showed me 
that return by auto-ref is horribly broken.

Basically, the only thing it does is check if the very last value 
it returns is a ref, but a ref to what? The possibilities of 
returning a ref to a local are HUGE. For example, simple 
returning the index of a tuple, or of a static array, and you're 
in it deep:

//----
import std.typecons;

auto ref foo(T)(auto ref T t)
{
     return t[0];
}

void main()
{
     int* p = &foo(tuple(1, 2));
}
//----

Here, both foo will return a ref to a local. But the compiler 
won't see, and more importantly, it gets blind sided because it 
*can't* see it (AFAIK).

These are trivial examples, but imagine what happens if you start 
mixing in templates, in particular, things like 
std.algorithm.map, that returns its front by auto-ref.
This is combined with an improvement I'm trying to make to 
*aryFun, to infer return type reference of. The two *do*not* mix. 
At all.

This investigation leads me to believe that using auto ref in 
anything but trivial template code.

--------

There have been lots of talks about such problems recently in 
regards to safe code and escaping references, but I just realized 
that auto-ref is just as vulnerable to the problem as is safe 
code.

There were talks about safe code banning the taking and/or 
passing/returning references if the compiler couldn't prove this 
was safe. I'd suggest, staying on the side of safety, we also 
apply this to auto ref, and ban it from returning a ref if it 
can't *prove* the object returned is not a local.

Am I wrong in my analysis? More importantly, how would this mix 
with DIP 25 (http://wiki.dlang.org/DIP25) ?