That is fair, but if you try to sample for usage in real world projects, "reflection" as an example seems to have much more usage than "contracts".

Searching for contract_assert on GitHub, I only found TrenchBroom projects using it; apart from a few projects hiding contract_assert behind a preprocessor macro, which seems like an entirely unintended way to go about contracts.

I also tried to search for "pre(", but only found false positives.

In contrast, there are hundreds of files across repositories on GitHub using std::meta.

Maybe, so; we should all just use Rust in the holy and consecrated name of memory safery. Oh, whoops, Rust is not memory safe, and usage of unsafe is widespread in some algorithmic work, the kind of already-difficult work where the extra difficulty of unsafe worsens matters.

https://materialize.com/blog/rust-concurrency-bug-unbounded-...

https://github.com/rust-lang/rust/blob/main/library/core/src...

What does that have to do with C++? Enormous pressure was put on C++ to change, in the name of holy memory safety, and C++ contracts was claimed by some to directly address memory safety. And the pressure came in large part from the Rust Foundation and related parties and individuals, such as Steve Klabnik. Funnily enough, Steve Klabnik is very active on C++ forums, and he has "strong forum-voting powers" both here and elsewhere.

That push for holy memory safety was not done in the interest of improving C++ or improving the state of programming. If they, Rust Foundation and company, had had an interest in improving C++, they would instead have tried to add the actually good parts of Rust to C++, namely tagged unions and pattern matching.

Their focus is also in many ways not beneficial to neither Rust nor programming generally, since a lot of energy is spent hiding the actual issues of Rust, thus diverting resources and attention away that could have been spent improving and fixing Rust.

Perhaps Mozilla was right in paying mental-medication-taking Steve Klabnik the least for his community-focused work, after all, his primary focus was not engineering, and he might harbour a burning hatred and envy for actually talented engineers. Or maybe Mozilla should have fired him while they had the chance long ago.