On 4/27/26 10:31, Jan Schultke via Liaison wrote:
>   * There is a work-in-progress page at https://github.com/sg22-c-cpp-standard-compatibility/sg-compatibility/blob/main/c2y-compatibility.md <https://github.com/sg22-c-cpp-standard-compatibility/sg-compatibility/blob/main/c2y-compatibility.md> tracking the compatibility status between C2y and C++. This provides a summary of all adopted C2y changes and what we're doing on the C++ side. Note that this isn't meant to imply that every change to C automatically needs to be adopted in C++, but deciding to adopt changes from C usually needs to be a conscious decision (in favor or against), especially for library features.

Why is this phrased from a C++ viewpoint only?
It's similarly a conscious decision whether C wishes to
adopt a change from C++.

The vast majority of C++ library features are not eligible for being ported to C due to relying on compiler capabilities that are not available in C (e.g. templates). This also applies to many core language features, since they often build on other C++ features or are motivated predominantly by C++-specific problems.

We could track the C adoption of C++ papers, but the resulting table would be mostly blank, and the sheer volume of adopted C++ changes makes this quite challenging.
 
Further, in my view, C++ is a lot easier with incorporating C library features
as opposed to core language features: incorporating C library features "just"
needs a paper that rebases the C++ standard library on the next C standard,
whereas taking a new C core language feature into C++ requires a per-feature
paper for C++ processing (and that hasn't happened for a lot of recent new C
features).

Yes, I agree. The library features tend to get adopted in bulk regularly; not so much for C core features.

I think it's nonetheless worth tracking C core features for adoption in C++. This goes especially for anything related to the preprocessor and for features that are used in headers and in top-level library APIs. Again, that isn't meant to imply that we're under some obligation to adopt those, or that it's even likely to happen, let alone happen in the next standard. The compatibility tracker is largely informative.