Hi,

We currently have this paragraph in
https://eel.is/c++draft/basic.extended.fp#7:

*Recommended practice*: Any names that the implementation provides for the
> extended floating-point types described in this subsection that are in
> addition to the names declared in the <stdfloat>
> <https://eel.is/c++draft/stdfloat.syn#header:%3cstdfloat%3e> header
> should be chosen to increase compatibility and interoperability with the
> interchange floating types _Float16, _Float32, _Float64, and _Float128
> defined in ISO/IEC 9899:2024 H.2.2.


>From a historical standpoint, it makes sense for this to exist because at
the time of design (C++23), there was no published C standard that had
those types, so we were not fully committed to extended floating-point
types in some areas of the standard. However, nowadays, I seriously
question this. Why don't we just provide the (optional) keywords instead of
recommending to the implementation that if it has keywords, it picks
something along the lines of these ones?

I think it's obvious that if an implementation supports, say, std::float16_t,
it will use _Float16 as a keyword spelling for the type alias. GCC and
Clang already do that, and I would assume that MSVC is going to provide the
same keyword at some point.

Standardizing the keyword itself would be beneficial to people writing
headers that compile in both C and C++. C There are tons of existing uses
of these keywords in C already (
https://github.com/search?q=language%3AC+%2F%28%3F-i%29%5Cb_Float%5B0-9%5D%2B%5Cb%2F+-is%3Afork&type=code),
and from the perspective of a C user, there isn't a great reason to avoid
the keyword spelling. It's a bit ugly, but so is life. This means that
whenever you want to have a C/C++-interoperable header that uses
half-precision floats, you need to come up with some compatible spelling
that works in both languages, like making a new my_lib_float16_t alias or
macro.

This seems like an unnecessary hurdle to me. The keyword _Float16 exists in
C and isn't going away anytime soon, and the keyword _Float16 exists in a
C++ compiler providing the type as well, in practice. We may as well
standardize existing practice then and make writing those headers easy.

I understand that those underscore names are not very aesthetically
pleasing and feel a bit out-of-place for C++, but that's not a deal-breaker
to me.


Yours
Jan