On 17/09/2021 13.56, Aaron Ballman wrote:
> FWIW, it's sounding more and more to me like there's high risk for
> user confusion and incompatibilities between C and C++ in this space
> and we should consider a joint meeting with the C Floating Point Study
> Group to see what can be done in both committees to reduce that
> likelihood. I'm planning to discuss P1467 in SG22 on Oct 1, and I will
> invite the CFP group (as well as others in WG14) to attend.

Well, given the current scheduling, it is very likely that C
just goes ahead with what they have (they've been working on
it for years), and C++ won't do anything for C++23 due to timing
constraints.

Maybe one way out of the naming problem is to say that
C++ retains its model that std::float16 (etc.) is an alias to
an unnamed fundamental type plus say that the typedef _Float16
is introduced in <cmath> and <math.h>, referring to that same type.

This way, C code that uses _Float16 would just work if the code
included <math.h>, which seems likely.
Yet, we get away with not officially introducing _Ugly keywords
in C++. And since a type name and an alias pointing to that type
is indistinguishable in C++, compilers might just happen to treat
_Float32 as a keyword instead of an alias.

Jens