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.

No, that isn't what reinterpret_cast is for. reinterpret_cast allows for the construction of a pointer or reference of a type that corresponds to the actual type of the object at the provided location. It can't be used for type punning except in certain cases involving non-aliasing types.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> On Behalf Of Paul Caprioli via Std-Proposals
Sent: Monday, August 25, 2025 20:26
To: std-proposals@lists.isocpp.org
Cc: Paul Caprioli <paul@hpkfft.com>
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?

I think you would either have to propose that such types do alias (in which case no changes to reinterpret_cast would be needed) or you need to come up with a more novel solution, perhaps something similar to what is explored in P2626.

Consider:

void f(std::float64_t *pf64) {
  *pf64 = 2.0;
}
double g(double *pd) {
  std::float64_t *pf64 = reinterpret_cast<std::float64_t*>(pd);
  f(pf64);
  return *pd;
}
void h() {
  double d = 1.0;
  assert(g(d) == 2.0); // true???
  assert(d == 1.0);    // true???
}

Assuming an assert enabled build, what are your expectations for those asserts? Today, an implementation is allowed to assume that a write through a pointer of type std::float64_t cannot affect the value of an object of type double. At what point would an optimizing compiler be required to synchronize the write of *pf64 in f() with the read of d in h()? Note that an optimizing compiler does not necessarily perform operations in the order they appear in the source code.

In my opinion, unless the non-aliasing type restrictions are removed, the following is required:

1. An operation very much like std::start_lifetime_as() is needed in place of reinterpret_cast.
2. Another operation, perhaps the same operation with types reversed, must be written at the point where the programmer wants changes to be synchronized.
3. In between those two operations, the memory must only be accessed via std::float64_t.
   
4. Before and after both operations, the memory must only be accessed via double.
   

Tom.

Also, insight into the intended purpose of std::float32_t and std::float64_t would be welcome.