>> I would rather have the interoperability than these optimizations. Agreed. For example, optimizations based on the non-aliasing of std::float64_t and double seem as likely to be wrong (based on programmer intent) as to be right. > Then rather constructs specifically allowing something identical for the interoperability case. Does the sentence above suggest inventing novel lifetime-related functionality in the standard library? Or, a novel type that is a union of std::float64_t and double and has interoperability properties? I would suggest, instead, making interoperability the default (as was done for complex in [complex.numbers.general]). I don't know how to word it properly. Given floating-point types T and U, where T and U have the same set of values and every value in T has the same exact representation in U and vice versa, `reinterpret_cast<cv U*>` magically works. P1467R9 "considered allowing implicit conversions between pointers to two different floating-point types that have the same representation", but this was "voted down by EWG in Prague". I'm not asking for that. I'm proposing to allow reinterpret_cast to work. (And, therefore, C-style casts.) In fact, I would like to see this made retroactive to C++23. Is a defect report a possibility? If not, maybe there could be a note (assuming it's true) that all known C++23 implementations allow this to work even though the standard did not mandate it. The intention seems to have been interoperability. Hmmm, if long double and double are both IEEE binary64, does any known implementation optimize based on TBAA? Aside: In [expr], I would suggest changing [conv.double] to [conv.fp] as an editorial change to the reference of the subsection on "Floating-point conversions".