This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[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 7.6.1.9 [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 7.6.1.9 [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 inventedtemporaryvariable t (9.4 [dcl.init]). The effect...
Proposed resolution (September, 2013):
Change 7.6.1.9 [expr.static.cast] paragraph 3 as follows:
A glvalue, class prvalue, or array prvalue 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 theglvaluevalue is 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.