[menaerus]

> C++ makes breaking changes all the time,

Please don't spread misinformation. Breaking changes are actually almost inexistent with C++. The last one was with the COW std::string and std::list ~15 years ago with the big and major switch from C++03 to C++11. And heck, even then GCC wouldn't let your code break because it supported dual ABIs - you could mix C++03 and C++11 code and link them together.

So C++ actually tries really hard _not_ to break your code, and that is the philosophy behind a language adhering to something that is called backwards-compatibility, you know? Something many, such as Google, were opposing to and left the committee/language for that reason. I thank the C++ language for that.

Introducing new features or new keywords or making stricter implementation of existing ones, such as narrowing integral conversions, is not a breaking change.

[ajross]

> Introducing [...] new keywords [...] is not a breaking change.

This is some kind of semantic prestidigitation around a definition for "breaking" that I'm not following. Yes, obviously it is. New keywords were valid symbol names before they were keywords.

Makes me wonder if the "don't spread misinformation" quip was made in good faith.

[menaerus]

It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.

[ajross]

Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time.

That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that the bulk of the industry has decided to abandon for new work. The large majority of people doing work on this code are doing minimal-change updates, and nonsense like this is how you end up with rules like "We have to deploy on Ubuntu 20.04 still because the AbandonWare 4.7 library doesn't work on later version".

And it's avoidable, but not if you run around lying to people and yourself about what a breaking change is. Again, look at how C does this. The C standard writers actually know that they're updating a legacy environment and care deeply about full backwards compatibility.

[menaerus]

Nonsense. Adding more keywords to a language is avoidable? Or making the compiler stricter in checking the integral promotions is avoidable? Sure, it is, but only if you stick compiling all of your code with C89. You're barking at the wrong door.

[ajross]

Adding keywords can be done compatibly. Again, I'm not making things up. A C18 compiler can absolutely build K&R C programs that are probably older than your parents. (C23 did roll back some stuff, to much gnashing of teeth, and seems unlikely to become a default mode for that reason. Most projects are holding at C99/C11.)