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