3 ms·
It's not that it's suspect, it's that equivalent Rust code will not compile. This is one of the things the borrow checker does, if something is atomic, you can
by samatman 4y ago
It's not that it's suspect, it's that equivalent Rust code will not compile.
This is one of the things the borrow checker does, if something is atomic, you can't access it non-atomically, and this is assured at compile time.
The 'borrow checker up in arms' is the same thing as 'the type checker up in arms because I'm treating an integer like a string'.
- MauranKilom 4y agoMy point is that you can still have a race condition/logic bug, even if all your atomics are accessed atomically and all your borrows are fine (i.e. no data races). Note that I specifically wrote "[code] that assumes atomicVariable is true", not "code that accesses a shared resource under the assumptions that it has unique ownership because atomicVariable is true". Yes, this situation is much harder to produce by accident in rust - the language significantly raises the amount of things that are encoded/checked at compile-time and strongly guides you to safer designs. But I fail to see the "the equivalent Rust code will not compile" part. Here is a pretty stupid example including exactly the form of my original snippet: https://godbolt.org/z/6e18K85hT https://godbolt.org/z/6e18K85hT - You might get 2 or 3 printed after "see?". Or you might not get the first print at all (unlikely). And if you say "well nobody would write code like that" then that's exactly the point: It looks suspicious (even though it compiles).