This is about changing the default.

The issue with defaults is that people have projects that implicitly expect the default to be static.

So when the default changes, many projects break. This is maybe fine if it’s your own project but when it’s a few dependencies deep, it becomes more of an issue to fix.

There's a bootstrapping process that has to happen to compile the compiler. Moving up the language standard chain requires that compilers compiling the compiler need to also migrate up the chain.

So you can never be perfectly bleeding edge as it'd keep you from being able to build your compiler with an older compiler that doesn't support those bleeding edge features.

Imagine, for example, that you are debian and you want to prep for the next stable version. It's reasonable that for the next release you'd bootstrap with the prior releases toolset. That allows you to have a stable starting point.

A lot of software, and thus build automation, will break due to certain features that become warnings or outright errors in new versions of C++. It may or may not be a lot of work to change that, and it may or may not even be possible in some cases. We would all like there to be unlimited developer time, but in real life software needs a maintainer.

Well there are still some c++20 items that aren't fully supported, at least according to cppref.

https://en.cppreference.com/w/cpp/compiler_support/20.html

> Shouldn't the compilers be on the bleeding edge of the standards? What is the downside of switching to the newest standard when it's properly supported?

C++ standards support and why C++23 and C++26 are not the default: https://gcc.gnu.org/projects/cxx-status.html

> What is the downside of switching to the newest standard when it's properly supported?

They are discussing in this email thread whether it is already properly supported.

> It's one reason why people care so much about self-hosted compilers

For self-hosting and bootstrapping you want the compiler to be compilable with an old version as possible.

When a language changes significantly faster than release cycles (ie, rust being a different compiler every 3 months) it means that distros cannot self-host if they use rust code in their software. ie, with Debian's Apt now having rust code, and Debian's release cycle being 4 years for LTS, Debian's shipped rustc won't be able to compile Apt since nearly all rust devs are bleeding edge targeters. The entire language culture is built around this rapid improvement.

I love that C++ has a long enough time between changing targets to actually be useful and that it's culture is about stability and usefulness for users trying to compile things rather than just dev-side improvements uber alles.

> What is the downside of switching to the newest standard when it's properly supported?

Backwards compatibility. Not all legal old syntax is necessarily legal new syntax[1], so there is the possibility that perfectly valid C++11 code exists in the wild that won't build with a new gcc.

[1] The big one is obviously new keywords[2]. In older C++, it's legal to have a variable named "requires" or "consteval", and now it's not. Obviously these aren't huge problems, but compatibility is important for legacy code, and there is a lot of legacy C++.

[2] Something where C++ and C standards writers have diverged in philosophy. C++ makes breaking changes all the time, where C really doesn't (new keywords are added in an underscored namespace and you have to use new headers to expose them with the official syntax). You can build a 1978 K&R program with "cc" at the command line of a freshly installed Debian Unstable in 2025 and it works[3], which is pretty amazing.

[3] Well, as long as it worked on a VAX. PDP-11 code is obviously likely to break due to word size issues.

Right? I hope it never goes away, we should make the web more fun instead of sad and clean!

Anubis has been around for almost a year now, but it's also not particularly relevant to the content of the email thread.

Recently, on HN: https://news.ycombinator.com/item?id=44962529

I wouldn't have known that this is anime, if not for all the HN comments pointing that out.

Anubis is significantly less jarring than cloudflare blocks preventing any access at all. At least Anubis lets me read the content of pages. Cloudflare is so bleeding edge and commercial they do not care about broad brower support (because it doesn't matter for commercial/sales). But for websites you actually want everyone to be able to load anubis is by far the best.

That said, more on topic, I am really glad that C++ actually considers the implications of switching default targets and only does this every 5 years. That's a decent amount of time and longer than most distros release cycles.

When a language changes significantly faster than release cycles (ie, rustc being a different compiler every 3 months) it means that distros cannot self-host if they use rust code in their software. ie, with Apt now having rust code, and Debian's release cycle being 4 years for LTS, debian's shipped rustc won't be able to compile Apt.

Who cares tbh

See also discussion on https://news.ycombinator.com/item?id=44962529

Many people have said they don't like it, and all that did is make its supporters even happier that it's there, because it makes them feel special is some strange way.

You can always specify the language version in your compiler invocation.

> Presumably we still wouldn't enable Modules by default.

Seriously, why? They are broken. https://vector-of-bool.github.io/2019/01/27/modules-doa.html