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) ?
