You can believe whatever you like, but the fact is that changes in C++11 and C++20 change the tradeoff between C++ and Rust in fundamental ways. The only way anyone could believe otherwise would be by knowing precious little about the topic.

While I did not use C++20, I did follow its new feature set, and did not see anything able to address the issues of C++:

- no way to express "lifetime relationships", they remain in comments or force you to work around the problem by using copied objects or worse, shared pointers. This resulted in very real bugs in our code due to a library returning structs that had to live shorter than some other object, without it being clear from the name of the struct. Coincidentally, this same library has a rust implementation, where keeping instances of this struct for too long is a compiler error.

- no blessed way to express thread safety in the type system

- terrible build system without a blessed package manager, which is not about to change because:

- they are still headers everywhere. While modules are technically in C++20, tooling is not ready today (save for MSVC). The module implementation is also dubious in that it seems to cater to any niche use case in existence which adds a lot of complexity (and new opportunities for ODR violations...), instead of going "clean slate" and providing a simple system (preventing the split between declaration and definition and not being orthogonal to namespaces would have been a good start)

- no ergonomic sum types. Sum types are very important to model business logic and it is hard to go back to languages lacking them. There are discussions of pattern matching for C++ but it's not in C++20.

Several of these issues are impossible to fix in an existing language without breaking an unreasonable amount of existing code, so I don't see future versions of C++ reversing the statu quo. I also don't really trust the committee to achieve simple, ergonomic solutions, when I look to eg what was done with modules or coroutines (here I heard that the solution is to use third party libraries, but while it is tractable in Rust it is much less so in C++ due to the lack of satisfying tooling).

You're welcome to elaborate if you disagree though.

In modern C++, you get the same benefits as are claimed for "lifetime annotations" by operating at a higher level. In effect, a library may adopt responsibility for what the Rust compiler would have enforced, and where it matters, they routinely do. This is no substantial burden. As a result, it has been a very long time since I last encountered a lifetime problem in my C++ code. Sum types work fine in C++. Pattern matching is an extra notational convenience on top of them.

Rust has many nice convenience features, but lacks numerous other powerful features C++ provides. But this is not a good place to go into detail. If you care, there is plenty of material online. The point remains that comparisons, if done at all, should be done based on knowledge about current facts, not suppositions and hearsay.