CWG2878 [expr.cast] C-style casts to rvalue reference to base class type and casting away const unintentionally ill-formed

[hubert-reinterpretcast]

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): expr.cast

Link to reflector thread (if any): N/A

Issue description: In https://eel.is/c++draft/expr.cast#4, we say:

If a conversion can be interpreted in more than one way as a static_cast followed by a const_cast, the conversion is ill-formed.

In the following, we see that the choice of static_cast can differ between casting to an lvalue reference type or an rvalue reference type.

struct A {};
struct B : A {};
const B b;
void f() {
  (A &&)b; // ill-formed?
  const_cast<A &&>(static_cast<const A &>(b));
  const_cast<A &&>(static_cast<const volatile A &&>(b));
}

Suggested resolution: If a conversion can be interpreted in more than one way as a static_cast, not arbitrarily adding cv-qualification and to an rvalue reference type if and only if converting to an rvalue reference type, followed by a const_cast, the conversion is ill-formed.

[t3nsor]

I wonder if what we actually mean is that it's only ill-formed if the two paths call different user-defined conversions. Because that's the only case where static_casts to a bunch of differently qualified variants of the destination type would actually be meaningfully different.

[hubert-reinterpretcast]

I wonder if what we actually mean is that it's only ill-formed if the two paths call different user-defined conversions. Because that's the only case where static_casts to a bunch of differently qualified variants of the destination type would actually be meaningfully different.

Although the suggested wording above does not actually fix this (because it only affects how to determine the ill-formedness), the current wording allows the C-style cast to slice (if it is not to be considered ill-formed):

struct A {};
struct B : A {};
const B b;
void f() {
  (A &&)b; // ill-formed?
  const_cast<A &&>(static_cast<A>(b));  // an unfortunate potential interpretation
}

[t3nsor]

Then, does it work if we say that an interpretation that doesn't call a constructor or conversion function (and all such interpretations are "the same") is preferred over one that does call a constructor or conversion function? And if all interpretations call a constructor or conversion function then it's ill-formed if it's not always the same function?

[jensmaurer]

CWG2878