Sure, usually the program can be changed to avoid the issue, but the key here is that the Rust compiler is wrong and needs to be fixed. Once fixed, the actual program fix also falls in place, as it cannot be compiled anymore.
https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
But getting back to the point, the C++ compiler doesn't have a borrow checker, so it can't have a bug in it. So it's on you, as the developer, to take care of all unsoundness.
While in Rust an issue is now filed, and with the fix, every future Rust program gets the fix.
The point of course was not that what you can do, but what you should do. All cases of safe Rust compiler producing unsound code should be fixed, but the same argument is more difficult to make for C++.
Sometimes should might be different of what you must. For example, if your program exhibits unsound behavior in safe Rust (or C++) code, it's probably a lot more practical to just change the program so that it doesn't, instead of updating the compiler, unless you happen to be a Rust compiler developer. But, at the same time, you should file an issue about it.
You can of course find C++ compiler bugs as well, although I expect that to be quite rare nowadays. But the typical case is that if a C++ program exhibits unsound behavior, there is no reasonable compiler fix for it.
Then there's of course Fil-C! This improves the situation greatly by converting most interesting cases of unsound behavior into runtime errors. It seems not everyone is happy with the runtime costs of making this happen, though. And you must compile everything with Fil-C. It doesn't work with Windows or MacOS either.
I simply cannot imagine a situation where you can’t find an alternate solution to a problem with the compiler. Even if the compiler would optimize your intended solution away, you can write an asm! macro.
It sounds to me like you have simply decided that one language cannot do what the other can because you personally would not do it, which is very silly.
If this is not the case then I restate my request for an example, for the third time - an example would prove the point you are not making through explanation.
I hold the argument that if the Rust compiler produces unsound behavior for safe Rust, then the compiler needs to be fixed.
As I see it, in either case, the program can be fixed, or the compiler can be fixed. The only difference as I see it is that the C++ spec does not expect the compiler to be fixed.
Did I misunderstand your post?
- either that the claims are paired as you say (the second one implying that the program cannot be fixed),
- or that the claims are completely distinct, that simply state the desirable state of things.
Using the second interpretation, the corollaries would be:
- there is (typically) no reasonable fix for the C++ compiler that would address the UB. Therefore to fix the UB all C++ programs exhibiting the same need to be fixed, which is hard, as the compiler will keep accepting them.
- once the Rust compiler is fixed, then all safe Rust programs exploiting the bug must now be fixed, or the compiler will reject them.
What I would sign under would be the second interpretation, not the first one. But I intentionally also selected the particular ambiguous form due to the cutesy, albeit misleading, symmetry of the statements.