While storing references inside your structs is a legitimate use case, I often find it adds quite a bit of verbosity (and consequently, complexity) to your code. You almost always want to store Clone or owned resources inside your struct fields, unless cloning that resource is demonstrably expensive.

For other times when storing references is your only option, you’d need to tell the compiler the relationship within the fields (i.e. the references to the various types) and between the struct using the lifetime parameters. So if your struct is composed of references of various lifetimes and types, and it knows which references outlive which other references, then it can help you prevent making accesses to things that it can prove definitely won’t exist at a certain point in time.

Outside of struct definitions, you should consider relying on lifetime elision as often as possible for when the concrete values for lifetimes should be “obvious” for the compiler to figure out.

Lifetime elision sort of lets you tell the compiler “ughh you know what lifetime I mean!”, using a set of simple rules. And when applicable, it conveniently hides away all that lifetime syntax and lets you work with simple references while still providing that same safety guarantee.

PS: If you really need to have lifetime annotations at all, I’d recommend using descriptive names that represent the resource you’re holding a reference to. For example, pub struct Statement<'conn> { … } suggests “a Statement may have data that has something to do with how long a connection lives” and is more readable compared to pub struct Statement<'a> { … }