This is a perfect summary of C++: substantially more complicated for substantial convenience.

Add Boost to the mix, as in this bug, and C++ becomes quite ludicrous really, but it can also combine efficiency, interoperability, and performance in a way that's quite difficult to achieve in other languages.

IMO, starting a good C++ project is an exercise in defining a specific language based on a subset of C++ more than anything else: done right, it can be a big lever, done wrong, it can be a big foot-gun.

If we make the underlying mistake in Rust (actually I did last week for unrelated code) by defining an operator implementation as simply calling itself rather than calling some concrete implementation, the compiler warns us, this is infinite recursion which probably wasn't what you wanted.

G++ has to emit code here to recurse infinitely, so it's not as though there's no opportunity to say "Huh, that probably won't be what they meant"

C++ compilers had warnings about infinite recursion for years now (since at least 2015 for clang)

Fair. That's actually crazy - I dug into this more and found the chosen Boost package fails tests on the chosen compiler, and so if they'd done even a cursory check to see if what they're doing could make sense there'd be red flags everywhere.

So the overall story is mostly "Our QA is garbage".

If it's at the "we never compile with -Wall -Werror" level of non-existent QA, I feel like that's an insult to garbage.

-Wall -Werror means that instead of being able to be used as a ratchet the set of "all" warnings in C and C++ became rusted in place. I sympathise with the instinct to write this in your compiler flags, but alas thanks to Hyrum's law this makes the future worse and so today people ask that you -Wextra and no doubt I'll eventually read of how C is fine so long as you -Wall -Wextra -Wevenmore -Wyetmore -Wandthese

It becomes substantial inconvenience as soon as you need to try to figure out why something doesn't work the way you thought it should.

You don't have to use all the fancy new features though. Personally I just stick to C++98 for the most part, unless I really want to use auto or lambdas for some reason, then I might use 11, but I won't go higher.

C++ 11 with lambdas is so much nicer than 98, but even if 14, 17, 20 and 23 have been minor in comparison the accumulated changes have been radical in making what was introduced in 11 into something really useful.

Making anything remotely useful out of templates was deeply into hideous SFINAE-land (substitution-failure-is-not-an-error) leading to horrible unreadable templates during 98 (and the variable-number templates in 11 while being useful only made it explode in horrendeous hacks).

"if constexpr" from C++ 17 and forward actually makes template-expansions not too horrid. you can do template expansions that reads mostly like regular if-elseif-else clauses (and I think that was perhaps part of the impetus for Zig's comptime, starting from this point with a clean slate instead of going through regular template evolution hell).

C++ pre- and post- C++11 are really different languages. It’s by far the biggest break (so far in my career) in how the language is used. I’ll gladly debate the detailed trade-offs of many of the newer features, but going back to a world before rvalue references is too horrifying to consider.

The horrendous hacks went away with concepts. SFINAE is dead. Spaceship operator, while perhaps not ideal from every perspective, radically simplifies the workload of implementing comparators.

Assuming the thing you want actually has a concept, sure.

You can define your own concepts. What is your point?

I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.

Not only can you define concepts, it is highly entertaining and educational. You can write a concept that makes a function only available on Tuesdays, for example.

I don't use templates hardly at all, and I find the added changes in later versions to seriously complicate what I would prefer to be much simpler, for example initialization rules... so that's one of several reasons I like to stick to older C++ versions.

Ah yea, why not settle with the 14 year old version?

The MAGA version.

Eh, you’re probably missing out. I remember C++20 being really convenient in comparison, though I forget why.

Eyeballing C++ 20, struct initialization with .member = blah is the one that jumps out.

But also, since the referenced bug involves Boost... I also haven't used Boost in years, since most everything I was using got pulled into modern C++ versions/STLs.

So if you're using C++98 and Boost, do yourself a favor and just switch to C++17 or 20 or whatever.

Scala has the advantage (and disadvantage) of not caring one lick about backwards compatibility. They were perfectly happy to burn it all to the ground and redo the language's syntax in v3. And even point releases of Scala frequently have breaking changes.

I respect that, but kind of lost patience with it when a new version of the compiler decided that my types were no longer decidable in code that hadn’t been touched for years. I tried for about 5 mins to fix it and then just thought “It’s not me, it’s you” and put scala down never to pick it up again.

I have observed significantly better useful features from Rust or Swift (or Scala) without horribly complicating the language like C++ does. More importantly, they migrate existing codebases and have migration tools instead of breaking old versions of syntax. Rust’s is the most ambitious here letting you mix match editions of the language within a single binary.