simple DIP1000 test fails?

[Jonathan M Davis]

On Thursday, November 02, 2017 18:54:15 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 11/2/17 6:10 PM, Jonathan M Davis wrote:
> > I haven't read DIP 25
> > recently, but I assume that the return on id is equivalent to marking
> > the
> > this parameter with return, in which case, the compiler knows where the
> > returned reference came from. So, returning by ref shouldn't be a
> > problem. The problem is simply taking the address, since the S is a
> > temporary, and that's already caught by @safe even without compiling
> > with -dip25.
> Right, the whole point of 'return' is to tell the compiler that the
> 'this' parameter is getting returned. IMO, this shouldn't even work on
> rvalues. It's not even the taking of the address, it's the fact that the
> address of the result outlives the rvalue. The compiler should be able
> to tell that if I call id with an rvalue, the resulting reference can't
> escape the expression.
>
> So it's somewhat of a cross between dip1000 and dip25, but obviously
> neither flags it.

I would think that it would be fine if you simply called a member function
on the rvalue. You couldn't pass the rvalue to any function accepting ref,
so the ref return would largely be pointless, but allowing a member function
to be called on the ref returned rvalue would mean that you could still use
the member function that returned by ref with an rvalue, whereas otherwise,
you'd be forced to assign it to a variable, which wouldn't be the end of the
world, but it would lose out on some flexibility that technically should
work just fine.

But I don't think that there's any question that what's allowed with that
ref return needs to be more restricted, since doing something like taking
its address or passing it to a free function that accepts by ref would be
really bad, and if disallowing calling ref return functions on rvalues was
the most reasonable way to stop that, then it wouldn't be the end of the
world.

- Jonathan M Davis