cargo::util::config::Config, lots of fields are cells. I was wondering what the reason is for this - why can’t methods that update fields just take
I don’t think there’s any real reason behind this except “it used to be convenient”. I think
Config::configure is the only method that needs to mutate most of this fields, and it is only called inside
execute at src/bin/cargo.rs:149.
It might be interesting to try to get rid of those cells and see if it works!
I’ve had more of a look, and it seems that having interior mutability here means you can pass Config around all over the place, without worrying about having more than 1 mutable reference. I think it should still not have interior mutability, as it obscures what is happening, so I’ll see if it’s fesible to change.
Yeah, I think some of thous cells are mutated down the line somhere, but there’s a high change that
&mut will suffice for most of them!
I’ve successfully removed a few of the Cells and all tests pass, but now I need to decide what to do with the remaining ones, especially
LazyCells. Currently they are lazily initialized, which improves performance if they are never used (to initialize
rustdoc requires a filesystem call, to initialize
easy requires loading a shared object file).
I could just load these eagerly, or load them in a worker thread, or leave them unchanged. What do you think is best?
LazyCell is a great abstraction, actually, because it allows to defer some work without introducing mutabilty and reference wrappers, like
RefCell, so I think it’s best to leave it as is.