C++ Logo

liaison

Advanced search

[wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)

From: Thomas Köppe <tkoeppe_at_[hidden]>
Date: Wed, 15 Sep 2021 16:43:24 +0100
Dear all,

I wanted to share with you a quick summary of our recent C and C++ liaison
meeting (that's SG22 in WG21), which happened last Friday. Some of this is
known to some of you, but maybe it will come as news to others, and maybe
we will want to consider some rapid reactions.

The meeting minutes are at
https://wiki.edg.com/bin/view/Wg21telecons2021/Teleconference2021-09-10.
Thanks a lot to Mark Hoemmen for scribing!

WG14 is getting ready to ship C23, and we saw two papers of liaison
interest that they shared with us, one major and one minor. On our end, we
shared one smaller, uncontroversial paper with them:


   - WG21 paper P2314
   <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2314r2.html> on
   "character sets and encoding" is making its way through WG21, and WG14
   agreed with the direction. They won't be able to make C use identical
   language in time for C23, but there don't seem to be any compatibility
   concerns, and they might harmonize their specification in the future.
   - WG14 paper N2739
   <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2378r0.pdf> (P2378
   for WG21) describes a change of how the C grammar is specified in terms of
   "blocks". This affects name lookup, in particular, how names from function
   parameter lists are found. We found no incompatibility with C++ here (i.e.
   in a program that is both well-formed C and C++, name lookup in the
   relevant cases produces the same results). C++'s grammar is specified
   differently, and C has to deal with things like compound literals and VLA
   function parameters (whereas C++ has to deal with function-try-blocks). No
   action required on our end, though.
   - The big one: P2423R0
   <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2423r0.pdf> is
   a report on new features in C23 that concern floating point types. I will
   elaborate below.

*Floating point matters*

Paper P2423R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2423r0.pdf> presents
a summary of several new features that have already been adopted for C23 in
the domain of floating points: this includes new types (some of them
optional) for specific-width types as well as decimal floating point types,
and a plethora of new library features (functions and macros). Members of
SG6 Numerics were on the call and have been aware of this, but I wanted to
raise awareness of these developments in a wider group: C will be adding
significant amounts of material to <limits.h>, <float.h>, <math.h>, as well
as to <complex.h> and <tgmath.h>. There will be many new types, and macros
to detect whether certain types exist. I wanted to call out a few detailed
concerns that we may want to consider:

   - If and when we rebase on C23, willl we be adding new overloads to
   accommodate those new types? Will we accept those new types for at all?
   - Currently, the new types are *exclusively* available in the
   _Reserved_name spelling (like "_Bool" was in C99), there is no set of
   "pretty" macros (like "bool" was in <stdbool.h>) -- that means that if C++
   decides to introduce new pretty names like (std::)float16_t, we have no
   immediately interoperable name (like "float16_t") that would be valid C,
   since there is no macro "#define float16_t _Float_16", say.
   - C continues to expand the "floating point environment" pragmas to
   include rounding modes; C++ continues to not have any equivalent notion of
   a floating point environment.

I'm aware that David Olsen et al. have been doing a lot of work proposing
new floating point types and type names for C++, and that there has already
been a lively discussion on that. I just wanted to make sure everyone has a
chance to see where C is going.

Best wishes,

Thomas
on behalf of SG22 -- C/C++ Liaison

Received on 2021-09-15 10:43:40