On Mon, 20 Sep 2021, Jorg Brown wrote:

> It seems very much against the spirit of the automatic-float-to-double
> conversion rule, for printf to work with float, but not _Float16 or _Float32
> or even _Float64. Surely this was an oversight on C's part? It seems the

See http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_206.htm regarding
why float _Complex does not promote to double _Complex: "This was
intentional because real float promotion to double is in Standard C purely
for compatibility with K&R. Since complex is new, that compatibility is
not an issue, and having it behave like real float would introduce
undesired overhead (and be less like Fortran).".

The same reasoning applies here. _Float16 and _Float32 were not in K&R C,
so there is no need for any promotions such as were for compatibility with
K&R.

The choice made so far has been not to provide printf support for the new
types at all (instead, strfrom functions are to be used to convert them to
strings, and presumably C++ should provide all the C++-style numeric I/O
and string conversion operations for them). If printf support were to be
provided (other than through explicitly casting to float / double / long
double), the natural form would probably be to include the N from _FloatN
explicitly in the printf format somewhere. We have %wN, %wfN printf
length modifiers now for intN_t, int_leastN_t, int_fastN_t (N2680,
accepted at the March 2021 WG14 meeting); it would certainly be possible
if desired to define such modifiers for floating-point formats (e.g.
%w128f to format a _Float128 in the %f style, %w16f for _Float16, etc.).

-- 
Joseph S. Myers
joseph_at_[hidden]