On Mon, 06 May 2013 11:31:05 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
