Well, however, there's no conversion categorized as narrowing in C. So I think we can arguably say the situation is not fundamentally different for `long double`, `double` and `float`.

We've standardized `sqrtf` and its friends in C++ and probably been expecting underlying C standard library implementations to provide them. This means that we also expect standard FP types to be implemented in the same formats and treated identically in calling convention(s) between C and C++.

I don't know why shouldn't we generalize such expectation/assumption to the type 0.0f32, etc..

Thanks,
Jiang An
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, November 26, 2025 20:46
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>
Subject: Re: [std-proposals] P3935R0 Rebasing <cmath> on C23



On Tue, 25 Nov 2025 at 18:12, Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> https://isocpp.org/files/papers/D3935R0.html

In section 2.1.1 above, there is "we don't consider std::float32_t to be C23's _Float32"
Is this correct?

https://eel.is/c++draft/basic.extended.fp#7 recommends _Float32 as an additional name for float32_t

If the implementation does define _Float32 as the underlying type of std::float32_t, it needs to make that type follow the C++ rules. For example, converting std::float64_t to _Float32 is a narrowing conversion, which is not the case in C. So the underlying type of std::float32_t (by any name) is never a type with exactly the same semantics as _Float32 in C.



It's not the same as float, even if float is IEEE binary32.