On 5/6/13 11:48 AM, Steven Schveighoffer wrote:
On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
<[email protected]> wrote:
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++.
I'm not sure I understand what you're suggesting.
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?
No. It's a very different thing handled by a special rule in C++.
I would note that my code continued to return
the rvalue for chained operator<< calls.
Of course.
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?
Yes. My point was to illustrate that a special rule that works in a
situation can't help another.
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.
It does. But binding rvalues to ref makes bounds check failures more
frequent, less predictable, and harder to debug. Failures will be more
frequent because there's more chance that a ref refers to a defunct
rvalue; less predictable because conditional execution may cause some
paths to be rarely exercised; and harder to debug because rvalues come
and go following implicit rules, not visible scopes.
Andrei
