> 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.