not really C++20 [LWN.net]

not really C++20

Posted May 1, 2026 4:02 UTC (Fri) by rolexhamster (guest, #158445)
Parent article: GCC 16.1 released

The default C++ standard is being advertised as "C++20" (specifically the GNU C++20 "dialect" which is just minor extensions), but this isn't really C++20 as it doesn't properly support modules, a major feature of C++20.

From GCC 16.1 release notes:

N.B. C++20 modules support is still experimental and must be enabled by -fmodules.

Not blaming GCC developers for this. It's more of a symptom of a broken (and seriously outdated) development model for the C++ language.

It's now mid-2026, and yet there is no C++ compiler as of today that actually properly supports the C++20 standard, "finalized" in February 2020, more than 6 years ago. Similar problem with the C++23 standard, "finalized" in February 2023.

state of C++20 compiler support: https://cppreference.com/cpp/compiler_support/20
state of C++23 compiler support: https://cppreference.com/cpp/compiler_support/23

Compare this with the development and deployment model of languages likes Python and Rust. When Python 3.14 is released, we get the full implementation of Python 3.14, not a "theoretical" half-complete implementation of Python 3.14.

not really C++20

Posted May 1, 2026 11:10 UTC (Fri) by jamesh (guest, #1159) [Link] (1 responses)

One possible outcome with something like this is that the feature becomes optional in a future version of the language. This happened with C99 variable-length arrays, which became optional in C11.

C++ modules seem like they would be a lot easier to implement if the language had a standard build system (like Rust has with Cargo, or Go has with it's "go" tool chain frontend). It's not the kind of thing you can easily implement in just the compiler. And to add support to a build system you need to know how the specific compiler you're using expects this all to work.

not really C++20

Posted May 1, 2026 15:11 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Eh. I've worked on implementing C++ modules for CMake. The issue, as I see it, is that the transition mechanism (header units) are all of the hardest cases of named modules at once. So projects can't make the jump without leaving their consumers behind, maintaining two variants of the build, or some cursed hybrid attempting to support both at once.

There's also the fact that modules are a "new" kind of dependency (well, Fortran had it, but hacks could work around that) that isn't natively supported by the likes of Makefile. It took C++ modules landing to convince Ninja maintainers to accept our patch from 2015 or so which was used by CMake for Fortran support (dyndeps).

I know that…some other developers have griped about CMake's approach, but there are definitely cuts one can make to the supported use cases to make the implementation simpler, but you're definitely leaving use cases on the floor when doing such decisions.

Luckily, the implementations were amenable to P1689 (my ISO paper for dependency communications) which provides the building block that build systems require to properly build modules in the most complicated scenarios.

Documentation for CMake's implementation is here (which includes said use cases and how CMake handles them): https://cmake.org/cmake/help/latest/manual/cmake-cxxmodul...

not really C++20

Posted May 1, 2026 18:44 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Compare this with the development and deployment model of languages likes Python and Rust. When Python 3.14 is released, we get the full implementation of Python 3.14, not a "theoretical" half-complete implementation of Python 3.14.

Yes, but you get the downside of that model, too. Python theoretically has a specification, but in practice what matters is what CPython does, not what the specification says. Also, the Python devs have an unfortunate habit of deprecating features that are still widely used, so code that was written a while ago may fail if it's run on a newer version. You win some, you lose some.

not really C++20

Posted May 3, 2026 8:58 UTC (Sun) by cyperpunks (subscriber, #39406) [Link]

Rust follows the same model, multiple implementation is very useful, it helps to uncover mismatch between specification and implementation, for this reason gccrs is very important.