In my opinion, I as a programmer shouldn't have to deal with __floating_point types of any kind.
doubles and floats are annoying as it is and I'm extremely happy that when <stdfloat> is implemented I don't have to touch them ever again.

When I want a uint32_t I want an unsigned integer with 32 bits of precision because it fits the target problem I want to solve. I don't want to use an unsigned int and play the game of russian roulette depending on which compiler/target platform combination the code was compiled and end up with "whatever"...

You have 4 base completely distinct integer types, short, int, long, and long long. But they can only be one of 3 sizes 16, 32, or 64bit... yeah int8_t can not be made with one of those (it's a signed char, as in a character)...

I want a 32bit IEEE 754 floating point and have it behave as such, not whatever a "float" just happens to be on a particular platform.

I see no reason why these well-defined types shouldn't just be the standard types (no additional headers required), and if your platform has some other wishy-washy type then put that in a system specific library (that I don't want too ever look at or care that it exists).

But that's just me.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]p.org> on behalf of Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 8, 2025 8:21:18 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Paul Caprioli <paul_at_[hidden]om>
Subject: [std-proposals] TBAA and extended floating-point types

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


--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals