return by auto ref horribly broken ?

[Zach the Mystic]

On Monday, 18 February 2013 at 11:10:38 UTC, monarch_dodra wrote:
> 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).

If you take the address of a value returning type, you must 
either ban doing it outright or treat the assigned pointer as 
dangerous. To take the address of a value type returned from the 
stack is especially dangerous - I can see banning it outright and 
I don't know what the spec currently says about this. My 
assumption would be that the only legal version of this would be 
the one which returns 'ref'. But tuple(1,2) is an rvalue struct 
type if I'm not mistaken, which means it would be passed as a 
value. The compiler should not allowed a type passed as a value 
(or any part of that value) to be returned as a reference, right? 
So I don't see a way to take the address of this result legally. 
I don't think it should return a reference at all with 
'tuple(1,2)'. That's all I know.