Date: Mon, 27 Apr 2026 16:22:15 +0200
Hi,
obviously you are both right ;-)
on Mon, 27 Apr 2026 12:51:15 +0200 you (Jan Schultke via Liaison
<liaison_at_[hidden]>) wrote:
> > 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).
Yes and no. Some features (such as atomics) are integrated into C++
syntax as templates, but the feature itself would make sense for C,
too. If such things happen, the semantics should be in sync.
> 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.
It would certainly not make sense to track *all* C++ features as you
say. But there are certain features that would make sense to be
tracked, regardless whether or not they are initiated from C or
C++. You see that already from the current table, many of the features
listed there are in fact features that come from C++.
So if we could track language features that are in the interesection,
I think that would be most helpful. So changes here should
automatically trigger an implication of the liaison group, and we
could have a list.
Come to mind, for example
- `constexpr`, in particular for functions
- lambdas or other kinds of local functional expressions
- changes to the declaratif interfaces in headers
- number suffixes
- `inline` for object names
- `const` definitions that lead to compile time constants
- atomics (in C they are largely a language feature)
- threads
- preprocessor
- integer types
- type traits (syntax in C++ is templatish, but many of them make
sense in C)
- changes in control and loop statements, such as `if` variables
> > 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.
Are they adopted other than when a whole new revision of the C
standard is incorporated?
> 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.
yes
Jₑₙₛ
obviously you are both right ;-)
on Mon, 27 Apr 2026 12:51:15 +0200 you (Jan Schultke via Liaison
<liaison_at_[hidden]>) wrote:
> > 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).
Yes and no. Some features (such as atomics) are integrated into C++
syntax as templates, but the feature itself would make sense for C,
too. If such things happen, the semantics should be in sync.
> 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.
It would certainly not make sense to track *all* C++ features as you
say. But there are certain features that would make sense to be
tracked, regardless whether or not they are initiated from C or
C++. You see that already from the current table, many of the features
listed there are in fact features that come from C++.
So if we could track language features that are in the interesection,
I think that would be most helpful. So changes here should
automatically trigger an implication of the liaison group, and we
could have a list.
Come to mind, for example
- `constexpr`, in particular for functions
- lambdas or other kinds of local functional expressions
- changes to the declaratif interfaces in headers
- number suffixes
- `inline` for object names
- `const` definitions that lead to compile time constants
- atomics (in C they are largely a language feature)
- threads
- preprocessor
- integer types
- type traits (syntax in C++ is templatish, but many of them make
sense in C)
- changes in control and loop statements, such as `if` variables
> > 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.
Are they adopted other than when a whole new revision of the C
standard is incorporated?
> 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.
yes
Jₑₙₛ
-- :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Université de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA antenne de Strasbourg :::::::::::::::::: Camus :: :: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr :: :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2026-04-27 14:22:20