On Monday, 18 August 2025 11:49:41 Pacific Daylight Time Paul Caprioli via Std-
Proposals wrote:
> Also, there would be a temptation to unconditionally alias `double` and
> `std::float64_t` without checking whether the former is IEEE binary64.

C23 Annex H says in H.2.2p4:

"An implementation that defines __STDC_IEC_60559_BFP__ and
__STDC_IEC_60559_TYPES__ shall provide _Float32 and _Float64 as interchange
floating types with the same representation and alignment requirements as float
and double, respectively."

That seems very inflexible to me: if the implementation defines the macros, then
the types must have the same representation and alignment, which means they
are effectively identical types.

In any case, C23 does not require the types to be arithmetic and does not seem
to define a macro indicating when they are (it just says the functions from
<math.h> and others won't be defined). Which means those interchange types
don't serve a purpose other than *as interchange*. Therefore, I don't expect
libraries to use them almost anywhere in their APIs.

PS: C has reserved "extended floating point" for the _FloatNx types because
they indicate extended precision over the base _FloatN type. All the new types
in the annex are not "standard floating types", with _FloatN classified as
"interchange floating types" and "binary floating types", and _FloatNx as
"extended" and "binary".

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering