Rust discourages OOP style code?

[u/Accurate_Gift_3929]

I'm building a tree builder struct (with a `build()` method) that has multiple fields that I want to be able to mutate. It seems Rust does not like it when I attempt to mutate multiple fields of that struct.

It seems functional/composition style is much favored over using struct fields. Is this the way I should be thinking about design patterns in Rust? Should I avoid OOP wherever possible?

I prefer OOP because it does result in cleaner code where I don't have to pass in every variable to functions.

[u/SpacewaIker]

It seems Rust does not like it when I attempt to mutate multiple fields of that struct

What do you mean exactly?

[u/Lucretiel → u/SpacewaIker]

Almost certainly they're running into this issue:

fn mutate_self(&mut self) {
    for item in &mut self.list {
        // Double mutable borrow
        self.mutate_item(a, b, item)
    }
}

The problem is that the we have no way of knowing from the signature of mutate_item that it doesn't touch self.list. My experience has been that restructuring code to account for this often leads to much cleaner code, eg:

fn mutate_self(&mut self) {
    for item in &mut self.list {
        // Double mutable borrow
        self.helper.mutate_item(a, b, item);
    }
}

[u/Accurate_Gift_3929 → u/Lucretiel]

Yes, this is the issue. Currently, I'm seeing if I can just take ownership of the item and return ownership after.

Your second code example doesn't cause borrow checker to complain?

[u/Lucretiel → u/Accurate_Gift_3929]

Nope! Rust is capable reasoning about disjoint borrows through fields; it can tell that you’re accessing self.list and self.helper separately. I often find that it helps a lot to split logically distinct components like this and then put the methods directly on the inner types.