8 ms·

Yes, it is hard to use mutable shared values Rust. This is exactly the point.

• creshal 10y ago
  So how do you avoid it?
  • nikbackm 10y ago
    Use unsafe or wait for the improved borrow-checker?
  • nercury 10y ago
    Well, you either uniquely mutate, or keep the value immutable. Usually you construct the pipeline to switch between these as you need. If you need to share the result from one mutation to the other, you can do it by passing a simple immutable value that communicates the state change to other mutation, but don't try to do both at the same time. This is simply a good practice enforced at compile time. Of course, sometimes these rules prevent some valid cases, but overall it is worth it. If we are talking about HashMaps, the Rust std lib has useful Entry api to for get-or-insert use cases. In rare cases where you need to share the value between different parts of the system, there are primitives you can wrap your value in and enable reference counting, as well as internal mutation (even if wrapper is immutable, it provides safe api for mutation). In cases where the concurrency is needed, there are mutexes, channels, and multiple libraries to parallelize the code (like rayon or crossbeam).
    • AstralStorm 10y ago
      The problem is there is nothing like "atomic mutable", equivalent of C++ std::atomic with at least sequential consistency. So you get to drop all safety often instead to have shared mutability.
      • dbaupp 10y ago
        This is wrong. There is a std::sync::atomic module, along with types like Mutex and RWLock.
  • burntsushi 10y ago
    There's no single solution to the problem, which is perhaps one reason why folks new to Rust might stumble over it. You can't just get two aliased mutable pointers to the same region of memory in safe code. Sometimes the borrow checker can't quite see through everything. Consider this trivial example, which will fail the borrow checker: let mut owned = vec![1, 2]; let x = &mut owned[0]; let y = &mut owned[1]; That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. Namely, neither `x` nor `y` refer to the same point in memory, but the borrow checker still forbids it. What's the solution to this problem? Well, it depends on what problem you're trying to solve. One popular approach is to change the representation of your reference from a pointer to an index: let mut owned = vec![1, 2]; let ix = 0; let iy = 1; Now, in order to dereference your reference, you need to do `&mut owned[ix]` instead of simply `{STAR}x`. There are various trade offs to this choice of course, including the fact that `&mut owned[ix]` will likely be bounds checked. (Bounds checking could be turned off by using `unsafe { owned.get_unchecked_mut(ix) }`.) But there are more solutions to this problem! Here's another: use std::cell::Cell; let owned = vec![Cell::new(1), Cell::new(2)]; let x = &owned[0]; let y = &owned[1]; x.set(10); y.set(20); println!("{:?}", owned); This uses a concept known as "interior mutability" to permit mutating through a borrowed reference. `Cell` only works for `Copy` types ("plain old data"), whereas you'd need to use `RefCell` for non-copy types like `Vec<T>` or `String`. Finally, we can come full circle and use the `split_at_mut` API on slices to get two mutable views into the same slice. This is a good example of something that is ultimately implemented using `unsafe`, but exposes a `safe` interface: let mut owned = vec![1, 2]; { let (xs, ys) = owned.split_at_mut(1); let x = &mut xs[0]; let y = &mut ys[0]; *x = 10; *y = 20; // The added scope is used so that the mutable // borrow of `owned` is done before borrowing it // again to print its contents below. } println!("{:?}", owned); There are various trade offs to each of these approaches and which one you use depends on the problem you're trying to solve. Of course, the criticism of "I just want to use mutable pointers dammit" is valid, because Rust will, for the most part, force you to think of another way of solving your problem (unless you're OK using `unsafe` and raw pointers). We occasionally pay a price for it when the borrow checker isn't quite smart enough. In the example I've shown in this comment, it's obvious what the borrow checker should do, but in a real program, it's rarely so simple.
  • CyberDildonics 10y ago
    shared mutable values are also called globals
    • junke 10y ago
      Only when they are globals, though.