Type-based aliasing analysis (TBAA) enables desirable optimizations, so it's generally undefined behavior to read or modify memory through a pointer to a different type. The standard specifies when the result of reinterpret_cast can be used to access memory. For example, for any object z of type std::complex<T>, reinterpret_cast<T(&)[2]>(z)[0] is the real part of z. Supposing that double is IEEE-754 binary64 and ptr has type double*, is it safe to reinterpret_cast<std​::​float64_t*>(ptr) and then use it to read or modify memory that is an array of doubles? I could not find that this is allowed, so I would like to float the idea for such a proposal. I'm not sure whether the standard does/can/should say anything about implementation-specific types representing floating-point values. For example, on Apple hardware I might want to use intrinsics from arm_neon.h, which has typedef __fp16 float16_t; and provides vld1_f16(const float16_t *). Given const std::​float16_t* ptr, is it safe to use vld1_f16(reinterpret_cast<const float16_t*>(ptr)) ? Note that the __fp16 data type is not an arithmetic data type. The __fp16 data type is for storage and conversion only. Arm recommends that for new code, you use the _Float16 data type instead of the __fp16 data type. __fp16 is an Arm C Language Extension. Also, the C++ standard has Recommended practice: Any names that the implementation provides for the extended floating-point types described in this subsection that are in addition to the names declared in the <stdfloat> header should be chosen to increase compatibility and interoperability with the interchange types _Float16, _Float32, _Float64, and _Float128 defined in ISO/IEC TS 18661-3 and with future versions of ISO/IEC 9899. I'm wondering whether the standard does/can/should say anything about reinterpret_cast between _Float16* and __fp16* and using the resulting pointer to read or modify memory. Regards, Paul