I personally don't see how in most commonly used platforms (x86_64, ARM, etc..) std::float32_t and std::float64_t would be anything other than an alias to float and double, no conversion necessary.
If they have same bitwise representation and requirements, then I assume that yes you could just reinterpret_cast between them, that's what reinterpret_cast is for. But then again, probably unnecessary as I assume they will just be aliases of the thing you already wanted so casting is unnecessary.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Paul Caprioli via Std-Proposals
Sent: Monday, August 25, 2025 20:26
To: std-proposals_at_lists.isocpp.org
Cc: Paul Caprioli <paul_at_[hidden]om>
Subject: Re: [std-proposals] TBAA and extended floating-point types

IEEE 754-2019 defines floating-point formats.
All formats can be supported as arithmetic formats; that is, they may be used to represent floating-point operands or results.
Specific fixed-width encodings for binary and decimal formats are defined for a subset of the formats.
These interchange formats are identified by their size and can be used for the exchange of floating-point data between implementations.

I assume std::float16_t is a C++ arithmetic format.
Note that it is unrelated to Unicode. See: https://en.wikipedia.org/wiki/UTF-16

The C++ standard section [basic.extended.fp] does not make clear (to me at least) the intended purpose of std::float32_t and std::float64_t.
In particular, interoperability with arrays of float and double seems awkward at best.

I'm requesting feedback as to whether reinterpret_cast should be made to work between floating-point types having identical representations.
Should I bother to author such a proposal or would I be wasting my time?
Also, insight into the intended purpose of std::float32_t and std::float64_t would be welcome.


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