The standard does say that they are indeed a distinct fundamental type. But would otherwise work as if they are the same.

My argument would be in this case that reinterpret_cast has a fundamental function and it's behavior should be well defined.
I.e. if you overwrite its bits that should have a visible side effect and the compiler shouldn't just be allowed to optimize that away.
And if compilers have trouble figuring that out when optimizing code, then they should just do a better job period.

It's a source code, not source suggestion.

In any case std::bit_cast should also do the trick, which should be at most a trivial copy if not a no-op.


________________________________
From: Paul Caprioli <paul_at_[hidden]>
Sent: Monday, August 25, 2025 8:56:02 PM
To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: RE: [std-proposals] TBAA and extended floating-point types

The C++ standard prohibits aliasing standard floating point types (float, double, long double) to extended floating point types.

In [basic], [conv.rank]:
An extended floating-point type with the same set of values as exactly one cv-unqualified standard floating-point type has a rank equal to the rank of that standard floating-point type.
Floating-point types that have equal floating-point conversion ranks are ordered by floating-point conversion subrank.
The subrank forms a total order among types with equal ranks.
The types std​::​float16_t, std​::​float32_t, std​::​float64_t, and std​::​float128_t have a greater conversion subrank than any standard floating-point type with equal conversion rank.

I agree we ought to be able to just reinterpret_cast between pointers to floating-point types having identical representations.
Is there an argument against standardizing this?


-----Original message-----
From: Tiago Freire <tmiguelf_at_hotmail.com>
Sent: Monday, August 25 2025, 11:36 am
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Paul Caprioli <paul_at_[hidden]>
Subject: RE: [std-proposals] TBAA and extended floating-point types

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_[hidden]
Cc: Paul Caprioli <paul_at_[hidden]>
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