> To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler? Right. And this reduces to th

> To phrase it differently: the code that gets verified by the compiler is safe, but is all safe code verifiable by the compiler? Right. And this reduces to the halting problem, so in theory the compiler cannot know that all safe code is safe. In practice, I'm saying that not just syntactically, but in your code's design, the compiler is more likely to be right. It's a bit like Chesterton's fence. You can bypass the lifetime checks if you just have the confidence to say "yes, I'll use `unsafe` here and it's fine because these reasons". As you're writing your "SAFETY" comment, you may very well find yourself not so confident anymore. And indeed, often this compiler-induced "stop and think" prevented you steaming ahead with a bug. Now, the borrow checker is not perfect. I don't know how far away from "all but NP-complete cases" it is. My experience is that it's almost always right, and I've only had to put a seemingly needless "drop" statement to placate it. But they're working on it. A new one is coming: https://daily.dev/posts/rust-s-new-borrow-checker-is-coming--llpxltaj6 https://daily.dev/posts/rust-s-new-borrow-checker-is-coming-... And once again this old blog post of mine comes to mind: https://blog.habets.se/2020/12/Bypassing-safety-check-for-obviously-safe-changes.html https://blog.habets.se/2020/12/Bypassing-safety-check-for-ob... In any case "by arranging your program in a way the compiler can verify" I think is not accurate, because the overlap between "correct" and "compiler can verify" is nearly complete, though yes the latter is a strict subset of the former. In other words I don't write Rust to make the compiler be able to verify it, but to make it correct. And nearly always that means the compiler can verify it too.