3 ms·
The error message in this case might be something like "foo became None after verifying it to be Some". This could happen, for example, if incorrect unsafe code
by gue5t 10y ago
The error message in this case might be something like "foo became None after verifying it to be Some". This could happen, for example, if incorrect unsafe code in another thread concurrently mutates foo through a raw pointer. My point is that of course while writing them you don't think your unwraps will fail, but if they do, it's good to have a reminder of what's going on. Even if the expect never fails, the message provides additional documentation for those reading the code.
- kzrdude 10y agoYou'll like Rust, because concurrent mutation of a value is impossible if you hold a `&` or `&mut` to the value. So this can in fact be ruled out by the programmer.
- Retra 10y agoIt's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.
- kzrdude 10y agoAny use of `unsafe` that breaks unrelated safe code is broken and buggy; if that scenario would happen like you describe it, the code is breaking Rust's aliasing rules: that's possible using `unsafe` but invalid and leads to UB.
- Retra 10y agoI'm not talking about 'uses of unsafe', I'm talking about code that is unsafe. Much of that code is not even written in Rust, so there's no 'unsafe' to use.
- kzrdude 10y agoOk, so code that is memory unsafe (broken!). One must still say "unsafe" to bring it into Rust (to use ffi, or make a safe wrapper); so there is still a clear location in the Rust code that is to blame.
- cynicalkane 10y agoConcurrently modifying aliased memory (`&` references and pointers) is undefined behavior. Not just in Rust, but in just about any language. As an aside, alias unsafety in Rust is always UB, even without concurrency.
- deleted 10y ago[deleted]