This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Moved to DR at the February, 2014 meeting.]
In a declaration like
T&& r = static_cast<T&&>(T());
it is not clear what the lifetime of the T temporary should be. According to 188.8.131.52 [expr.static.cast] paragraph 4, the static_cast is equivalent to a declaration of an invented temporary variable t. The lifetime of the temporary is extended to that of t, but it is not clear what that lifetime should be, nor if the subsequent binding of t to r would affect the lifetime of the original temporary. (See also issue 1568.)
Notes from the February, 2012 meeting:
The reference is bound to the xvalue result of the static_cast, so the lifetime of the temporary is not extended and this example results in a dangling reference.
Proposed resolution (February, 2012) [SUPERSEDED]:
Change 184.108.40.206 [expr.static.cast] paragraph 4 as follows:
Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration T t(e); is well-formed, for some invented
temporaryvariable t (9.4 [dcl.init]). The effect...
Proposed resolution (September, 2013):
Change 220.127.116.11 [expr.static.cast] paragraph 3 as follows:
A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible with “cv1 T1” (9.4.4 [dcl.init.ref]). If the
glvalueis not a bit-field, the result refers to the object or the specified base class subobject thereof; otherwise, the lvalue-to-rvalue conversion (7.3.2 [conv.lval]) is applied to the bit-field and the resulting prvalue is used as the expression of the static_cast for the remainder of this section. If T2 is an inaccessible (11.8 [class.access]) or ambiguous (6.5.2 [class.member.lookup]) base class of T1, a program that necessitates such a cast is ill-formed.