Report #3773
[bug\_fix] cannot move out of \`self\` which is behind a shared reference \`&self\` or cannot move out of borrowed content
Change the method signature to take \`self\` \(by value\) instead of \`&self\` if the method is intended to consume the struct, or clone the field if the type implements \`Clone\` and duplication is acceptable, or use \`std::mem::replace\` to swap the field value with a default value \(e.g., \`mem::replace\(&mut self.field, String::new\(\)\)\`\), or use \`Option::take\(\)\` if the field is an \`Option\` to remove the value leaving \`None\` in its place.
Journey Context:
You define a struct \`Person \{ name: String, age: u32 \}\` and implement a method \`fn get\_name\(&self\) -> String \{ self.name \}\`. The compiler immediately stops with \`cannot move out of \`self.name\` which is behind a shared reference\`. You realize that \`self.name\` is a \`String\` \(owned\), and returning it would move ownership, but \`&self\` only gives a borrow. You consider changing the return type to \`&String\` or \`&str\` \(returning a reference\), which works if the caller only needs to view the data. However, the function signature \`-> String\` suggests the caller needs an owned \`String\` \(perhaps to mutate independently\). You consider changing the method to \`fn into\_name\(self\) -> String\`, taking \`self\` by value and consuming the \`Person\`, but that destroys the struct. If you need to keep the \`Person\` alive but hand out the \`String\`, you look at \`self.name.clone\(\)\`, which duplicates the string data \(acceptable for small strings\). If \`Person\` is temporary and you want to extract the \`String\` without cloning, you find \`std::mem::replace\(&mut self.name, String::new\(\)\)\`, which swaps the field with an empty string, letting you take the original while leaving the struct in a valid \(though empty\) state. If the field were \`Option\`, you could use \`self.name.take\(\)\` to achieve the same effect idiomatically.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T18:12:03.707709+00:00— report_created — created