How can you mutate (or avoid the need to mutate) nested, constructed fields in Rust, without making everything mutable, when Cell can't be used?
<p>I'm pretty new to Rust and I've been slowly following <a href="http://jadpole.github.io/arcaders/arcaders-1-0/" rel="nofollow">an arcade game tutorial</a> which has been a great help with the concepts it goes through.</p>

<p>In <a href="http://jadpole.github.io/arcaders/arcaders-1-9/" rel="nofollow">part nine</a> of the tutorial, in which the main menu is created, the author suggests 'homework' for the reader of making the labels on the main menu ("New Game", "Quit") animate their change in size when focused and unfocused, rather than jump to their idle/focused size. This is where I have been having difficulty...</p>

<p>The basic layout of the relevant parts of the code before I started to implement the change is the following:</p>

<pre><code>// equivalent to 'menu option'
struct Action {
    /// function executed if action chosen
    func: Box&lt;Fn(&amp;mut Phi) -&gt; ViewAction&gt;,
    label: &amp;'static str,
    idle_sprite: Sprite, // smaller (32)
    focus_sprite: Sprite, // larger (38)
    // ...
}
impl Action {
    fn new(phi: &amp;mut Phi, label: &amp;'static str, func: Box&lt;Fn(&amp;mut Phi) -&gt; ViewAction&gt;) -&gt; Action {
        // ...
    }

struct MainMenuView {
    actions: Vec&lt;Action&gt;,
    selected: i8,
    // ...
}
impl MainMenuView {
    pub fn new(phi: &amp;mut Phi) -&gt; MainMenuView {
        // ...
    }
}
impl View for MainMenuView {
    fn render(&amp;mut self, phi: &amp;mut Phi, elapsed: f64) -&gt; ViewAction {
        // ...
        for (i, action) in self.actions.iter().enumerate() {
            // ...
        }
    }
}

fn main() {
    ::phi::spawn("Arcade Shooter", |phi| {
        Box::new(::views::main_menu::MainMenuView::new(phi))
    });
}
</code></pre>

<p>&nbsp;</p>

<p>My first thought for the animation was to make it dynamically create a sprite based on an interpolated size between <code>idle_size</code>and <code>focus_size</code> using time elapsed since focus change using methods on <code>Action</code> to focus and defocus to change a <code>current_size</code> field that would be used to generate a sprite for a <code>sprite</code> field.</p>

<p>This required a mutable binding of the <code>Action</code> struct, which took me a little while to work out as there was no <code>let</code> binding anywhere, but seemed to be just about possible by changing the constructor: <code>Action::new(...) -&gt; &amp;mut action</code>, and lots of explicitly marking lifetimes (which had its own issues, but this is getting too long as it is). I then realised that the <code>MainMenuView</code> would have to be mutably bound as well, at which point I stopped this path (I hadn't managed to successfully compile since starting it), as this seemed a really inelegant solution that made basically everything mutable, surely defeating the point of rust's immutability default...</p>

<p>I then wondered whether I could just create a new <code>MainMenuView</code> with a new <code>Action</code> with the new <code>sprite</code>, which could probably work (changing view to another <code>MainMenuView</code>), but this seems like a really wasteful way to just change the size of some text and again is pretty inelegant.</p>

<p>After that, I remembered <code>Cell</code>, but when trying this to make the <code>actions</code> for <code>MainMenuView</code> a <code>Vec&lt;Cell&lt;Actions&gt;&gt;</code>, I found <code>Cell</code> only works with <code>Copy</code> types. This might have been ok (I don't have enough experience to know), but the <code>func</code> field of <code>Action</code> does not implement <code>Copy</code> (and I'm not sure if it can?) and so <code>Action</code> cannot <code>#[derive(Copy)]</code>. Dead end without restructuring a large section of the program to not have <code>func</code> in <code>Action</code>?</p>

<p><strong>This is the end of my main question - basically, what do you do when you have structs nested and you want to have a deep field mutate, but can't put a <code>Cell</code> around it (afaik)? And is this a structural issue with the code such that I should be avoiding this issue in the first place?</strong></p>

<p>I also realised that a solution with a <code>Vec&lt;Sprite&gt;</code> in <code>Action</code> with a lot of sprites of different sizes for the transition would eliminate the need for any of the aforementioned to be mutable. This instinctively felt slightly hacky, as it was effectively hardcoding something that shouldn't have to be. I could also see issues in the implementation with properly aligning to frames (I'm new to synchronising things with frame timing as well), and working for a maximum fps - although the number of sprites could be dynamically created based on the max fps when <code>MainMenuView</code> is constructed...</p>