4 ms·

Ok, but I repeat: what is the use case? Yes, this allows me to do things like add an item to a Vec without modifying it in place, but why would I want to do th

• masklinn 9y ago
  > Yes, this allows me to do things like add an item to a Vec without modifying it in place, but why would I want to do that? What's the situation where that's helpful? The context is obviously shared concurrency (hence the library using Arc period), so you can cheaply get a shared immutable structure and manipulate it on your side (without sharing it back), and if necessary share/swap it in at some point, they provide cheap read/copy/update cycles. With regular collections Rust would preclude misuses but that would still require either deep copies upfront or fairly large exclusive critical sections.
• the8472 9y ago
  It might be useful for RCU data structures in multithreaded code
  • cryptonector 9y ago
    Absolutely. This is one very good use case. Say you have a configuration to read and share with all threads. Each thread can make local changes that will not be visible to the others. The API looks like it's mutating the shared object, but it's actually mutating a copy.
• caconym_ 9y ago
  One example: storing a large text buffer in a persistent data structure (e.g. a rope) can allow you to maintain a space-efficient history of "snapshots" simply by keeping pointers to older versions of the buffer.
• Groxx 9y ago
  No ability to mutate -> no mutable ownership complications. Ever. And that's probably the biggest pain-point for people using Rust. Not necessary, but can simplify things, by encouraging(/forcing) simpler use of data by default.
  • cztomsik 9y ago
    But you get another pain-point in return - having to replace the whole state at root position, which in turn leads to redux.
    • Groxx 9y ago
      That's a pretty normal way to handle immutable-data systems, yes.
• divs1210 9y ago
  maintain history/rewind state to any previous stable time, like git/datomic.