Because if you bind a variable in a pattern, it is using move or copy semantics per default. You can override this with the ref or ref mut keywords so that the variable binds to a (mutable) reference of the value instead. From the reference:
By default, identifier patterns bind a variable to a copy of or move from the matched value depending on whether the matched value implements Copy. This can be changed to bind to a reference by using the ref keyword, or to a mutable reference using ref mut.
Edit: Note that if you remove the as_mut call on subtree, you also don't need ref mut, as your subtree is a reference pattern. When binding to reference patterns, ref [mut] can be omitted, as it is implicitly added by the compiler:
Thank you for your quick reply. On a separate note, what's exactly the reason that I cannot call subtree.as_mut() there? I also tried subtree.as_mut().take() which doesn't work either. Is it related to certain restrictions around mutable getters? I haven't used Rust for a while so things got a bit hazy for me...
I'm not exactly sure. When we bind the result of calling as_mut to its own variable and make types, implicit dereferencing and reborrows explicit (snippet below), the structure becomes a bit clearer. Inside the loop we assign subtree to a (splitting) reborrow from subtree_iter (which itself is a reborrow from subtree). Looks to me like you can't have cycles like that between two mutable variables reborrowing from each other.
Edit: I think my assessment is correct, the cycle between subtree and subtree_iter is the problem. If we don't let subtree reborrow from subtree_iter inside of the loop, subtree_iter is not alive when we write to subtree after the loop: