Hi all,
with the release of C23, the C++ standard needs to be updated too.
We're looking for a volunteer or a group of volunteers to help with that effort. I'm cheekily adding the people who did this for C11 in hope of getting them interested in doing the same thing again. :)
Some notes on the changes to the standard library in C2x, taken from
https://en.cppreference.com/w/c/23 (I'm ignoring the core language changes, that's somebody else's job ;-)
Removed from C:
- Support for calling realloc() with zero size (the behavior becomes undefined)
This will affect C++ as we just incorporate realloc by reference. Seems OK, it just needs to be documented in Clause C.
- __alignof_is_defined and __alignas_is_defined
We already deprecated the latter ready to remove it when we do the rebase. For some reason C++ never had the former (probably an error), so we're adding it and deprecating it via an LWG issue:
https://cplusplus.github.io/LWG/issue4036
- static_assert is not provided as a macro defined in <assert.h> (becomes a keyword)
- thread_local is not provided as a macro defined in <threads.h> (becomes a keyword)
These don't affect C++, we never had those macros (and don't have <threads.h> at all).
Deprecated in C:
- <stdnoreturn.h>
Not present in C++ at all.
- Old feature-test macros
__STDC_IEC_559__
__STDC_IEC_559_COMPLEX__
Not present in C++.
- asctime()
- ctime()
We incorporate these by reference, but C++ already provides other facilities for formatting times without depending on global state.
- DECIMAL_DIG (use the appropriate type-specific macro (FLT_DECIMAL_DIG, etc) instead)
- Definition of following numeric limit macros in <math.h> (they should be used via <float.h>)
INFINITY
DEC_INFINITY
NAN
DEC_NAN
We'll pick up these changes by reference too. Seems fine for them to be deprecated in C++, we already have the FLT_DECIMAL_DIG, DBL_DECIMAL_DIG etc. macros, as well as std::numeric_limits.
__bool_true_false_are_defined
This is already deprecated in C++23, ready to remove it at a later date.
- New library headers <stdbit.h> and <stdckdint.h>.
The former would come along with _BitInt if we add that to the core language, and should be explicitly noted as absent otherwise.
The latter provides extremely useful functionality, but we probably want a more C++-like interface, and maybe add them to <numeric> alongside the new saturation arithmetic functions. LEWG should decide whether to incorporate <stdckint.h> as-is if we're not going to have something like it in time for C++26. I'll raise this with LEWG.
- decimal floating-point math functions
We don't have DFP (there was a TS but it's outdated and needs a revision).
- floating-point formatting functions
Redundant with std::to_chars and std::to_string, but I see no harm in incorporating them by reference.
- library support for UTF-8
We already have char8_t (and its atomic cousin). mbrtoc8 and c8rtomb are better than nothing, but being tied to the global C locale makes them of limited use in C++. We really want something that works with the encoding of an arbitrary std::locale (or at least a ::locale_t, or just POSIX iconv) not dependent on global state. I've emailed SG16 about the two new functions.
- memset_explicit
I assume we want this.
- POSIX functions memccpy, strdup, strndup, gmtime_r, localtime_r, extensions for strftime and wcsftime.
I assume we want these too (the time ones are improvements on what's in C today, but still less flexible than std::chrono).
- extensions for fscanf and fprintf function families.
You can already do all of this with iostreams and std::to_string and std::sto* and there's a proposal for std::scan, so meh. But we might as well have them.
- timespec_getres
I doubt anybody cares about this in C++. I doubt most people even know it exists. I'm OK if it we take it as long as people continue to be unaware it exists.
- Macro constants for width of integer types
- Additional numeric limit macros for floating-point types
We already have std::numeric_limits for it, but I still use these (but maybe that's because I'm implementing a stdlib and for normal users std::numeric_limits is the right choice). We might as well have them.
- Library version-test macros
I don't think we want these, we have a different way of doing feature-test macros. We might want some new __cpp_lib_xxx macros that depend on the underlying libc ones though.