[TillE]

The compatibility target is C++17, which I imagine was chosen primarily to avoid the complexity of modules in C++20. They're also excluding non-trivial preprocessor macros, and saying that you'll probably have to write a bit of glue code in some unusual situations.

It's a very realistic take on C++ interop, but still well beyond anything offered by other languages.

[formerly_proven]

If the goal of Carbon is considered to be an off-ramp for Google's C++ projects, then Carbon does not have to evolve with C++. Google can just say "we use up to C++17 and Carbon" for these projects.

[humanrebar]

Yeah, but there will probably be a window in which that offramp is generally interesting. If the worldwide C++ codebase moves along, carbon becomes less accessible as a viable choice.

Ironically, Google (googletest, gRPC, etc.) has been more agressive than most in dropping support for older C++ standards.

[pjmlp]

Since Apple and Google have focused on their own languages, clang steam went out, as no one else seems that interested in improving ISO C++ support, rather the LLVM foundations, which require C++17 as basis.

If the likes of Intel, AMD, ARM, IBM, Embarcadero,.... don't step up in ISO C++ support at upstream, clang will stay mostly C++17 with some bits and pieces from C++20.

It is already ironic, that after so many years of being joked for their non-standard extensions, VC++ has the best ISO C++20 support.