3 ms·
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
by 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 agoThe 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 agoThis is wrong. There is a std::sync::atomic module, along with types like Mutex and RWLock.