Lifetime elision for users of structs or traits with manually-defined lifetimes

tl;dr: Compiler should not force you to manually state lifetimes of traits and structs which had their own lifetimes stated explicitly, unless they cause new ambiguities.

Longer version:
I'm studying Rust lately and I ran into a little problem. I was writing a stupid game using rust-sfml and I thought it was too much of a waste to keep recreating the same objects over and over again.

The code was something like this:

pub struct RenderingComponent {
    window: RenderWindow,
}

impl RenderingComponent {
    pub fn draw(&mut self) {
        let texture = // get texture from file
        let sprite = // create sprite from texture
        self.window.draw(&sprite);
    }
}

So I've decided to cache everything but as soon as I've tried to cache the Sprite object, I had problems. Sprite has an explicit lifetime declaration because it stores an immutable reference to the texture.

pub struct Sprite<'a> {
    texture: &'a Texture,
}

When I tried to cache it (with something like a Vec<Sprite>), that lifetime declaration got into my code and hit it like a bomb. Now I had to rewrite RenderingComponent as RenderingComponent<'a>, which started a cascading effect all the way up to the main function. In the end I've decided against caching the Sprite instance and went on recreating the instance from scratch on every loop iteration.

It would be nice if the compiler could look at Sprite's manually defined lifetime and just sparred me the pain of rewriting all my code making all lifetimes explicit. (Which is a skill I still have to acquire, btw).

Am I missing something here because of my inexperience with the language or is it a valid claim?

Start with Rust's lifetime-elision rules and the Sprite, RenderingComponent, and main-function examples in the issue. Determine whether the requested behavior can be specified without introducing ambiguity, and document a concrete language-design decision or proposal as the definition of done.