Mfcttrf

In the following simple example, why can't ref2 be bound to the result of min(x,y+1)?

#include <cstdio>
template< typename T > const T& min(const T& a, const T& b) return a < b ? a : b ; 

int main()
 int x = 10, y = 2;
 const int& ref = min(x,y); //OK
 const int& ref2 = min(x,y+1); //NOT OK, WHY?
 return ref2; // Compiles to return 0

live example - produces:

main:
 xor eax, eax
 ret

It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.

[class.temporary]

5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]

6 The third context is when a reference is bound to a temporary.
The temporary to which the reference is bound or the temporary that is
the complete object of a subobject to which the reference is bound
persists for the lifetime of the reference except:

• A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
  the call.


• The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
  at the end of the full-expression in the return statement.


• [...]

You didn't bind directly to ref2, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.

Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2; does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.

This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2 to the result of min, which is a reference. It doesn't matter that that reference references a temporary. Only b extends the lifetime of the temporary; it doesn't matter that ref2 also refers to that same temporary.

Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2 would do the Correct Thing^tm, then depending on the runtime values of x and y+1 the lifetime is extended or not. Not something the compiler is able to do.

I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:

The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:

• a temporary materialization conversion ([conv.rval]),


• 
  ( expression ), where expression is one of these expressions,


• subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,


• a class member access ([expr.ref]) using the . operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,


• a pointer-to-member operation ([expr.mptr.oper]) using the .* operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,


• a const_­cast ([expr.const.cast]), static_­cast ([expr.static.cast]), dynamic_­cast ([expr.dynamic.cast]), or reinterpret_­cast ([expr.reinterpret.cast])
  converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,


• a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or


• a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.

According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.

The lifetime of the y+1 temporary is extended once when bound to the reference parameter b. Here, the prvalue y+1 is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min function returns, however, ref2 is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1 temporary is destroyed at the end of the definition of ref2, and ref2 becomes a dangling reference.

There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.

It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo"; is an indirect reference binding) is clearly not relevant here.

Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:

struct S int x; ;
const int& r = S42.x;

However, in C++14, the expression S42.x became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.

One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x case. However, there is no statement to this effect in the standard, either.

StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1 temporary, which will instead be destroyed at the end of the full-expression containing the call to min. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1 temporary in the question from surviving until the end of main.

Thus the question remains: what is the principle that explains why the binding of ref2 to the temporary in the question doesn't extend that temporary's lifetime?

The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x case.