On Mon, Aug 25, 2025 at 2:56 PM Paul Caprioli via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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?
>

Well, we allow that between `int` and `unsigned int` for what I suspect are
historical reasons (probably that C originally didn't have unsigned types),
but we don't allow it between, say, `long` and `long long` even if they
have the same representation (e.g. 64 bits, little-endian, with no padding
bits).

There are two main objections to extending the list of exceptions to the
strict aliasing rule. Some people don't like it ideologically: they feel
that it weakens the type system and concedes ground to the side that
prefers to view objects as bags of bits. Others are unwilling to give up
the optimizations that are enabled by strict aliasing rule (e.g. the
compiler being able to assume that a write to a `long` glvalue cannot
change the result of a subsequent read from a `long long` glvalue).


>
>
> -----Original message-----
> From: Tiago Freire <tmiguelf_at_[hidden]>
> 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_[hidden]> 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
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*