CWG 2024-11-19

The last of the concerns is resolved by the resolution of issue 2879.

Notes from the May, 2015 meeting:

CWG reaffirmed the status quo for dynamic_cast but felt that const_cast should be changed to permit binding an rvalue reference to types that have associated memory (class and array types).

The specification of dynamic_cast in 7.6.1.7 [expr.dynamic.cast] paragraph 2 (and const_cast in 7.6.1.11 [expr.const.cast] is the same) says that the operand of a cast to an lvalue reference type must be an lvalue, so that

  struct A { virtual ~A(); }; A &&make_a();

  A &&a = dynamic_cast<A&&>(make_a());   // ok
  const A &b = dynamic_cast<const A&>(make_a()); // ill-formed

The behavior of static_cast is an odd hybrid:

  struct B : A { }; B &&make_b();
  A &&c = static_cast<A&&>(make_b()); // ok
  const A &d = static_cast<const A&>(make_b()); // ok
  const B &e = static_cast<const B&>(make_a()); // ill-formed

(Binding a const lvalue reference to an rvalue is permitted by 7.6.1.9 [expr.static.cast] paragraph 4 but not by paragraphs 2 and 3.)

There is implementation divergence on the treatment of these examples.

Also, const_cast permits binding an rvalue reference to a class prvalue but not to any other kind of prvalue, which seems like an unnecessary restriction.

Finally, 7.6.1.9 [expr.static.cast] paragraph 3 allows binding an rvalue reference to a class or array prvalue, but not to other kinds of prvalues; those are covered in paragraph 4. This would be less confusing if paragraph 3 only dealt with binding rvalue references to glvalues and left all discussion of prvalues to paragraph 4, which adequately handles the class and array cases as well.