@vertigo `t` is referencing `tc`, look at the `create_texture` function signature.
You need to store `tc` for a time >= `t`.
You are probably going to end up with a self-referential struct:
The field `self.t` will need to reference `self.tc`.
It's a bit hard, but it will solve your problem.
To get self-referential structs working, see this SO question https://stackoverflow.com/questions/32300132/why-cant-i-store-a-value-and-a-reference-to-that-value-in-the-same-struct
@ranfdev I've looked at the signatures and the structs themselves, and I'm not finding where this reference is happening.
From another discussion on this topic, it looks like I might have misunderstood how lifetime annotations work; but, even after reevaluating structure lifetimes, I'm still not seeing why I'm getting the error.
I'll check the link you provided as soon as I'm in front of a computer again, thanks for the link. Hoping it will shed some light on my woes.
@vertigo `create_texture` takes `&self, ...` and returns a `Result<Texture<'_>,...>`
The lifetime `'_` refers to the lifetime of the only reference available, so `&self`.
In this case you can imagine `&self == &'_ self`
That means `t` is referencing `&tc`.
@ranfdev Right; but I can show in my code that tc out-lives t. What I can't get is why Rust doesn't think this is the case.
@vertigo in the code you posted, tc is _not_ outliving t. Tc gets dropped at the end of the function, while t keeps living inside the struct.
Rust sometimes is over aggressive, but not in this case.
The sdl2 crate authors designed the API in this way and rust is simply enforcing it, correctly
@ranfdev No; look after the call to the closure, where I take() the value of t again, and use it to clean up the texture. I fully expect t to be dropped at the end of the function, not to out-live it.
@ranfdev Also, let's leave the authors of the SDL2 crate out of this. I detect frustration levels seem to be rising for you, and I want to ensure you I'm not doing this to be annoying. My issues do not concern them, clearly. Let's just focus on my ignorance of what's happening.
I'm of course defending my code because (1) it helps me to clarify what I was thinking at the time, and (2) it provides you with that same insight which would help you find errors in the way I'm thinking about things. I'm not arguing to be prima donna here; I'm just trying to set a stage and clarify my thought processes as one would in any other academic setting.
I don't just want a cookie cutter solution that would fix my code; I already started with a working design, obviously. I want to understand why my refactor isn't working, so I can avoid these pitfalls again in the future, and not waste everyone's time again later on without good reason.
@ranfdev BTW, thanks again for that link. I wasn't aware that "move"-ing values actually did relocate values in memory. Thinking of lifetimes as "when things reside at an address" as distinct from "between allocation and dropping" is something I didn't know about, and this will help me going forward.
@vertigo Ah, I see...
You are right, t gets dropped at the end of the function
But rust doesn't care what you do with t after line 49. In 49 you are breaking the lifetimes guarantees, and that will trigger the error.
I can see the disappointment.
Linux geeks doing what Linux geeks do...