Rvalue references - The resolution

[Steven Schveighoffer]

On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 5/6/13 11:12 AM, Steven Schveighoffer wrote:
>>> If x > 100, the code is saving a reference to a destroyed temporary.
>>> If you couldn't see it, how many do you expect would see similar
>>> issues in even simpler and cleaner D code?
>>
>> No, I was wondering whether the compiler detects this and keeps the
>> temporary in scope (after all, it is in control of that temporary's
>> lifetime).
>
> It can't.
>
> Consider the body of min isn't known (eliminate templates etc). Then  
> what the compiler sees is a function call that returns a const ref. All  
> it can assume is it's a valid reference which it will subsequently bind  
> to the name given by the caller. The reference will refer therefore to a  
> destroyed rvalue (temporaries are destroyed at the end of the full  
> expression).

Well, given that we intend to infer some special behavior given the types  
of the parameters, I wouldn't think it was impossible to do the same  
here.  This would make the rvalue live beyond the expression, so maybe  
that's not allowed in C++.

> Your example is irrelevant to this discussion because returning an  
> rvalue and subsequently binding it to a const T& is a completely  
> different scenario.

I quote from your original rebuttal:

> ref int min(ref int a, ref int b) { return b < a ? b : a; }
> ...
> int x;
> fun(min(x, 100));

Which is returning an rvalue ref and subsequently binding it to a ref  
parameter of fun.

Isn't that the same thing?  I would note that my code continued to return  
the rvalue for chained operator<< calls.

> It would be also sound if it weren't for this:
>
> struct A {
>    A(const T& x) : a(x) {}
>    const T& a;
> };
>
> In _this_ case, initializing A with an rvalue of type T compiles and  
> subsequently runs with undefined behavior.

This seems like a separate ref problem.  But we don't have ref members, so  
it would require an address-of in D.  That should be forbidden, right?

> I repeat: binding rvalues to ref would make every mistake C++ has done  
> in the area, and add a few original ones. It is not a simple problem; if  
> it seems, more study is required.

I never said it was a simple problem.  I said that if you have solved the  
escape problem, the logic problem is difficult to solve, but not  
necessarily required.  Even though it is pointless to bind rvalues to refs  
in some instances, it's not dangerous memory-wise.

If you are saying we haven't solved the escape problem, that is news to  
me.  I thought the runtime check solves that.

-Steve