Rust compiler insists that I am passing an owned value, but it looks like it is behind a '&' reference

Question

I have a struct like below.

struct Test {
    field: Vec<String>,
}

I am passing a reference to this struct as a function argument. I have a second function that takes a &Vec<String>.

fn main() {
    let obj = Test { field: vec![] };
    takes_ref_to_struct(&obj);
}

fn takes_ref_to_struct(obj: &Test) {
    takes_ref_to_field(obj.field);
}

fn takes_ref_to_field(field: &Vec<String>) {}

This usage will not compile due to the error below:

error[E0308]: mismatched types
  --> src/main.rs:11:24
   |
11 |     takes_ref_to_field(obj.field);
   |     ------------------ ^^^^^^^^^ expected `&Vec<String>`, found `Vec<String>`
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected reference `&Vec<String>`
                 found struct `Vec<String>`
note: function defined here
  --> src/main.rs:14:4
   |
14 | fn takes_ref_to_field(field: &Vec<String>) {}
   |    ^^^^^^^^^^^^^^^^^^ -------------------
help: consider borrowing here
   |
11 |     takes_ref_to_field(&obj.field);

Obviously I can just add the suggested borrow, but why is this necessary? If I try to mutate the field

fn takes_ref_to_struct(obj: &Test) {
    obj.field.clear();
}

the compiler complains as expected

error[E0596]: cannot borrow `obj.field` as mutable, as it is behind a `&` reference
  --> src/main.rs:11:5
   |
11 |     obj.field.clear();
   |     ^^^^^^^^^^^^^^^^^ `obj` is a `&` reference, so the data it refers to cannot be borrowed as mutable

Answer 1

Rust is a strictly typed language. While the compiler does perform some transformations automatically, such as with self, in general you're responsible for providing a value of the desired type when you call a function.

The reason the compiler doesn't automatically do this when you have a reference is two-fold. First, if you did own the object, it would be valid to move the field. It would be confusing to automatically add references when the owned object is a reference, but not when it's owned. Regular, reliable behaviour is important in languages for human understanding, ease of tooling, and cross-implementation compatibility. The lack of consistent behaviour has made reliable tooling (e.g., code formatters) in Perl 5 very difficult and multiple implementations effectively impossible.

Second, the compiler doesn't evaluate ownership and borrows until after this stage of the compilation. Type checking happens before borrow checking, so the compiler has not evaluated borrow and ownership rules at this point. It would be very difficult to do borrow and ownership checking until the types are all resolved because the Rust compiler needs to have inferred and computed types to effectively do borrow checking, so practically you need to have the types correct first.

Answer 2

I think there is a simpler way to answer OP's question. @Chayim Friedman is correct that you do NOT need to destructure to get multiple mutable references to inner struct fields. That was my mistake. Here's a Rust Playground to test it out.

The dot operator in Rust automatically dereferences, i.e. it will try to use the owned struct underneath. When destructuring, the compiler does NOT deference. Because obj.field uses the dot (.) operator, there is an automatic dereference and it tries to move the inner data instead of assuming you want a reference.

Here is an example of destructuring to get a reference. But with this being said, it's going to be less work to just add the & onto your fields.

Destructuring:

let test = Test { field: vec![] };
let test_ref = &test;
let Test { field: field_ref } = test_ref; // field_ref will be a reference