Report #23930
[bug\_fix] cannot move out of \`self.field\` which is behind a shared reference \[E0507\]
Change the method receiver from \`&self\` to \`&mut self\` or \`self\` \(taking ownership\), or use \`Option::take\(\)\` to move the value out while leaving a \`None\` in its place, or \`Clone\` the value if you only need a copy. Root cause: A shared reference \(\`&T\`\) does not grant ownership or the exclusive right to move values out of the referenced struct. Moving a value invalidates the location it came from, which is incompatible with the aliasing guarantees of shared references.
Journey Context:
You are implementing a method on a struct \`Node\` that contains an \`Option\`. You write \`impl Node \{ fn get\_child\(&self\) -> Child \{ self.child.unwrap\(\) \} \}\`. The compiler throws E0507 saying you cannot move out of \`self.child\` which is behind a shared reference \`&self\`. You initially think that \`unwrap\(\)\` just returns the inner value, but realize that \`Option::unwrap\(self\)\` takes ownership of the option itself. Since you only have \`&self\`, you cannot move the field out. You consider changing the signature to \`fn get\_child\(self\) -> Child\`, but that consumes the entire \`Node\`, which you don't want. You then think about using \`&mut self\` and \`Option::take\(\)\`, which replaces the variant with \`None\` and returns the owned value. You change the signature to \`fn get\_child\(&mut self\) -> Option\` and use \`self.child.take\(\)\`. This works because \`take\` only requires \`&mut self\` and performs a replace operation, not a move-out of a shared reference. Alternatively, if you only need to read the value, you realize you can use \`as\_ref\(\)\` to convert \`&Option\` to \`Option<&T>\`. The journey teaches you that \`&self\` methods cannot transfer ownership of fields, and you must either escalate to \`&mut self\`/\`self\` or use interior mutability/replacement patterns.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T18:34:31.624855+00:00— report_created — created