Created on 2011-03-21.00:00:00 last changed 90 months ago
[Moved to DR at the October, 2012 meeting.]
Additional note, January, 2012:
An objection has been raised to the proposed resolution on the basis that it unnecessarily weakens the distinction between rvalues and lvalues, making it easier to create dangling references. Its status has therefore been changed back to "review" to allow further discussion.
Proposed resolution (August, 2011):
Change 220.127.116.11 [expr.reinterpret.cast] paragraph 11:
An lvalueexpression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. That is, a reference cast reinterpret_cast<T&>(x) has the same effect as the conversion *reinterpret_cast<T*>(&x) with the built-in & and * operators (and similarly for reinterpret_cast<T&&>(x)). The result refers to the same object as the source lvalue, but with a different type. The result is an lvalue for an lvalue reference type or an rvalue reference to function type and an xvalue for an rvalue reference to object type.No temporary is created,...
18.104.22.168 [expr.reinterpret.cast] paragraph 11, dealing with casting to reference types, only allows an lvalue operand. Presumably it should allow a glvalue operand when the target is an rvalue reference type.
|2014-03-03 00:00:00||admin||set||status: drwp -> cd3|
|2013-05-03 00:00:00||admin||set||status: dr -> drwp|
|2012-11-03 00:00:00||admin||set||messages: + msg4131|
|2012-11-03 00:00:00||admin||set||status: ready -> dr|
|2012-02-27 00:00:00||admin||set||status: review -> ready|
|2012-01-17 00:00:00||admin||set||messages: + msg3600|
|2012-01-17 00:00:00||admin||set||status: ready -> review|
|2011-09-06 00:00:00||admin||set||messages: + msg3434|