Understanding DIP 1000 semantics -- Where's the bug?

[ag0aep6g]

On Monday, 23 September 2019 at 19:11:46 UTC, Sebastiaan Koppe 
wrote:
> On Monday, 23 September 2019 at 18:46:40 UTC, Meta wrote:
>> On Monday, 23 September 2019 at 18:39:03 UTC, Sebastiaan Koppe
>>> Well, dip1000 doesn't do data-flow analyses. Which means the 
>>> compiler doesn't see that `x` escapes through `a`.
>>
>> AFAICT, according to dip1000 this code should not allow the 
>> result of `foo(x)` to be assigned to p, as it has a longer 
>> lifetime. Likewise, it should not allow foo to return &x 
>> without the parameter being annotated with `return`.
>
> It does all those things when you replace the body of foo with 
> just `return &x;`.

Not really. When you do that, DMD rejects the `return` statement, 
not the assignment `p = foo(x);`.

It works as expected when you mark the parameter with `return`. 
This has nothing to do with missing flow analysis. It's just a 
bug.

Maybe there is some clever idea regarding `ref` parameters and 
the implementation is just buggy, or maybe the bug is that 
they're not treated just like pointers.

I'd suggest treating them just like pointers. Seems to me that's 
the most straight-forward approach.

Meaning:

----
@safe:

int* fp(int* p) { return p; } /* This works. */
int* fr(ref int r)  { return &r; } /* So this should work too. */

void main()
{
     int x;
     fp(&x); /* This doesn't work. */
     fr(x); /* So this shouldn't work either. */
}
----