[vineek]

I completely agree with the points from this article. It is fundamentally infeasible to make all C and C++ code safe. The main reason, PAST code. There are countless lines of unsafe code already written. However, there is nothing magical about Rust's facilities (e.g. borrow checker) that make them inapplicable to FUTURE C and C++ code. I believe this is the only way forward for C and C++. They need to offer mechanisms that guarantee that any code written today can be provably memory and thread safe. That of course requires yet another tool in the myriad of tools that exist for C and C++.

[brundolf]

Language semantics matter. If a language doesn't place very strong meaning on certain things from the get-go, no amount of static checking will ever be able to guarantee certain traits of the code written in it, because it doesn't have enough information to work off of. And I'm not just talking about undefined behavior.

People have been writing safety checkers/linters/etc for C and C++ for decades. Many of them are very impressive and useful. None of them can ever be totally sound, as a fact of the languages themselves.

[wdpk]

by the same token you could say it's also fundamentally infeasible for Rust to be code safe, otherwise they would not have unsafe code... so in the end it's an article that says nothing interesting at all

[vineek]

The ability to occasionally opt-out is both a feature and a necessity because certain systems are inherently unstable and offer varying guarantees. I’m arguing for an opt-in feature in C++. Of course there is no panacea.