In this code I see a sequence. In words, where "I" = "struct":
I am lending a reference to one of my values, to set another one of my values.
Once the value is updated, I return a mutable reference to myself.
The sequence of events:
lend out a value of mine
resolve to completion the computation required to set another one of my values
with the computation now complete, I'm no longer lending out anything
it's now safe to share a mutable reference.
Is my thinking about an imperative sequence not right? In my thinking, the Rust account for the struct as a whole should not be a limiting factor.
Thanks to anyone that can help me reframe how I'm thinking about this!
- E
live update
Having articulated the question, I see an error in my thinking. The key:
self.header = get_header(&self.filepath).ok();
The value of self.header relies on a computation, that relies on a borrowed value. In itself, that's ok. Once the struct is shared as mutable, the computation with that mutable access could change self.filepath. That change would change the computation of self.header; not expected/corrupt. Because the referential integrity can no longer be relied upon => compiler error.
However, it still does not fully get me out of the "sequence"; intuitively there should be a way to contract in the timing... Lifetimes.