Agreed - not sure this is a good thing, making code and actions harder to reason about. Another reason to reconsider Rust...
I don't think you should dock Rust for pointing out bad practices that other languages simply don't notice. I think you can dock it for complaining about code that's really OK, which just happens to be exactly what they're trying to fix here.
For instance, I'd bet that most C or C++ apps in production that use concurrency have some concurrency bug somewhere, that's so rare that nobody has hit it yet (or the effect of the bug is minor). Those apps are running in production and serving a valuable purpose. Rust would force you to solve the edge case before deploying the app in production.
Occasionally, it's the right set of engineering tradeoffs to deploy something that produces useful results 99.9% of the time and crashes .1% of the time. (But, I guess you can say, you can always use Rust's 'unsafe' keyword to acknowledge that something isn't quite right but you're deploying it anyway.)
Yes, but unfortunately that doesn't describe the situation we are usually presented with. The developers most likely have not calculated that it runs fine 99.9% of the time and has specific failure cases that account for 0.1% of the time, they just don't know about the error. That is vastly different than making an engineering tradeoff, since the people engineering it don't even know there's a tradeoff being made, and thus can't make an informed decision about it.
In some sense, rust actually enables the situation you are presenting, in that it requires more explicit reasoning about behavior, and if you want to wrap a chunk in unsafe after calculating that it should only negatively affect the program operation 0.1% of the time, well then you actually are making a tradeoff.
I suppose it will mean a programmer might have to think a little harder if they want to manually preempt compilation errors, but fortunately the compiler is there to catch them if they don't get it right. The example the OP points out is a situation that will likely play out like the following in most circumstances:
- programmer adds new use of variable b.
- compiler points out an existing use of some other value a that could invalidate b, and, importantly, highlights all the moving parts (conflicting use of a, use of b that prolongs its lifetime, etc.) in the error message.
- programmer edits code to avoid the problem.