these features will eventually trickle down into the mainstream, kind of like C11 is doing at the moment

also, unless you're targeting embedded or a very wide set of architectures, there's no reason why you couldn't start using C23 today

Or in other words, for embedded and existing code: most use c99, some use c11 and nobody uses c23 until at least 10 years from now.

This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available.

I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20

Unless you can vouch for the C++ compiler, the best C++ portable code can offer today is C++17.

Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.

SDCC is a niche C compiler for 8-bit CPUs and is more uptodate than MSVC ;P

https://sdcc.sourceforge.net/

That's the nice thing with C: it's much easier for small teams to fully support than the latest C++ standards.

Now try to use it on the embedded deployments that require certification.

Most devices that are 6+ years old (as far as I can tell) use C99. If not C89. And/or C++17, if that.

That's A LOT of devices out there. A lot of which still get maintenance and even get feature updates (I'm working on one right now, C99).

So the claim that "C codebases generally use C11 or C17, and C++ code bases use C++20" intuitively sounds like totally untrue to someone working in embedded C/C++. I've been doing this for 15+ years and I've never touched anything higher than C99 or C++17.

If you're talking about gaming, sure. But that's not "C code bases generally".

most non-embedded and non-legacy codebases could use c23, that's not an insignificant set

I would argue that is an insignificant set.

Unless you think that code-bases created in the past year are a significant part of code bases that have been created since the inception of humanity.

Of course they will, just like they did in the past with C11, GNU extensions, or some of the individual features that are now rolled into C23. For example, the 0b notation for binary numbers is widely used in the MCU world.

The microcontroller toolchains are generally built on top of GCC, so they get the features for free. There are some proprietary C compilers that are chronically lagging behind, but they are not nearly as important as they used to be two decades ago.

The `thread_local` specifier is used on a few microcontroller platforms already, but would be absolutely illegal in C11 and before to use. However, it vastly simplifies memory management in a threaded context.

Why would I rather step into the world of C++ just to deal with that?

IIRC, performance and cost of thread local store varies greatly between platforms.

You have to know what you're biting into, before you use that.

One advantage of writing C code is that you don't have annoying discussions about what idiomatic code is supposed to look like, and what language subset is the right one ;)

For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust.

One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less annoying for us C library maintainers to support the people how want to compile their C code with a C++ compiler.

There is enough material in C, and related compiler extensions, to have similar discussions, starting from where to place brackets.

Maybe the C24 will define the One Right Way.

> C library maintainers to support the people how want to compile their C code with a C++ compiler.

Just tell them to go away.

Trying to write the subset of C and C++ is a fool's errand.

No inline functions in library headers, then.

Inline is mostly pointless in C anyway though.

But it might be a minor problem for STB-style header libraries.

It's not uncommon for C++ projects to include the implementation of an STB-style header into a C++ source file instead of 'isolating' them in a C source file. That's about the only reason why I still support the common C/C++ subset in my C libraries.

I'm with you on this. The feature list reads like a subset of later C++ standards that fit within C's (deliberately) rudimentary feature set.

You could, in theory, just use C++ and be done with it. But like any C++ project you'd need a pretty strict style guide or even a linter, but this time it would have to be extra restrictive lest you slide into full C++ territory. And maybe that's a major stumbling block for some people?

Won't any llvm/gcc supported target get the new version of C automatically? You won't get it in the vendor-modified ancient gcc toolchain for some other arch though.

There are many embedded platforms that do not gcc/llvm based compilers.

Also most companies making those platforms are not good at updating their toolchains. Expecting developers to compile their own toolchain, that is unsupported by platform vendor, is too much to ask.

Also GCC dropped support for certain architectures along the way, and even if you are willing to compile your own toolchain, it may not work for you.