float const& f = 1.f;
int const i = (int&) f;
Per expr.cast/4 this should be considered as, in order:
static_cast followed by a
reinterpret_cast followed by a
static_cast<int const&> followed by a
const_cast<int&> is viable; it will construct a prvalue int initialized from the float (with value 1), materialize it, bind it to a const reference, cast away const, and then perform lvalue-to-rvalue conversion resulting in an
int with value 1.
However, all compilers that I have checked instead initialize
i to 0x3f800000, indicating that they took the last option of
reinterpret_cast<int const&> followed by
const_cast<int&>. (If the UB offends you, consider changing int to unsigned char.)
This is somewhat related to CWG 909, involving conversion functions, which was closed NAD.
Should the Standard be changed to reflect implementation behavior, or should compiler vendors be persuaded to change their ways? I have a feeling that obeying the letter of the Standard here would silently break quite a lot of code, notwithstanding that such code would be pretty dubious already.