I mess around with rust every once in a while, and often run into issues where I want a struct to hold both some sort of system, and things created by that system that must not outlive it.

Most recently, using TextureCreator and Texture from the sdl3 crate put me in this situation:

struct State<'a> {
    canvas: WindowCanvas,
    tc: TextureCreator<WindowContext>,
    textures: Vec<Texture<'a>>, // textures must live as long as `tc`.
    // ...
}

Seems easy, right? Simple enough concept, I store a thing and the resources I used to create it, it's inherently obvious that they cannot outlive each other.

Now that I have my structure, I want to make a simple method to load textures.. and the borrow checker starts tormenting me!

For example, this initial approach does not work, insisting that the newly-added texture will not outlive self:

impl<'a> State<'a> {
    fn load_texture(&mut self, name: &str) -> Option<usize> {
        // ... omitted: load a texture, etc.
        self.textures.push(tex);
        // ... omitted: rest of the function
    }
}

I can resolve this by changing the self argument to &'a mut self... but then my main method seems convinced that I have taken an undying, infinite mutable reference to my state structure that lasts until the end of time.

Structurally, what do I do about this? I've seen suggestions to keep the "owning" thing (in this case the TextureCreator) and "owned" thing (Textures) in wholly different structures, never to meet, but.. that seems super messy, probably resulting in having to pass the two structures separately through tons of functions. I want to store "all the context" in one struct for a reason, and it seems silly to split it to avoid a situation that doesn't even seem self-referential in a way that matters.

3 posts - 2 participants

Read full topic