...
27 | meow: MeowIWantAMutRef::new(&mut inno),
| ----------------------^^^^^^^^^-
| | |
| | borrowed value does not live long enough
| argument requires that `inno` is borrowed for `'a`
28 | }
29 | }
The problem is that inno, as said in the error, doesn't live for long enough, meaning that it only lives for as long as the function call.
fn new() -> Self {
let mut inno = InnocentDependency {}; //<-+ Lifetime starts
Self { // |
inno, // | This is `inno`'s lifetime
meow: MeowIWantAMutRef::new(&mut inno), // |
} // |
} //<-+ Dropped here
and you'd end up with a dangling pointer. To fix this, I'd suggest having to pass in an InnocentDependency into IWannaOwnThings::new.
Another problem is self-referential structs where meow keeps a reference to inno and therefore refers to a member of the same struct. This is again fixed by following the fix I posted above. Look at this for more info
Well, I move inno into my struct, so it should be valid for as long as my struct lives, or am I wrong?
Why do you need a struct containing a value and a mut reference to the same value in the first place?
I basically need something to own the InnocentDependency and in my case I think it needs to be the same struct:
I'm using these Godot bindings to create a struct which behaves like a Godot class. To my knowledge I have not the option to pass additional parameters into the struct, I can only define a "constructor", see the godot_class! macro. Please correct me if I'm wrong!
Therefore, are there ways to do this or other options I could try? Thanks a lot!
Well, I move inno into my structure, so it [the reference created on construction of my struct] should be valid for as long as inno remains in the same scope.
Let's say that when you first move inno into the struct you then take a reference to the new struct's inno, and set it. Well then you move the struct out of the current function and into another function. In GC languages this would most likely be moving a pointer and that's it, but in Rust this moves the entire object (which is good in this case) and when it moves the entire object into the caller's stack memory it leaves the pointer dangling and therefore invalid. This would happen any time there is a move on the struct, like passing it (but not a reference to it) to a function, returning it, or dropping it.
The resulting code is really ugly though and I don't like it at all. If I had the choice, like @Aloso pointed out, I definitely wouldn't create a structure like this. If there is a better solution or I have missed something that makes me having to own the &mut ref in the same struct, I'd be very happy to know!
Going to mark this as solved. Thank you again for your help!