Unsafe code can easily produce “unbound” lifetimes – lifetimes which can be inferred as anything. These lifetimes are in fact even more powerful than
'static because e.g.
&'static &'a T is an illegal type, but an unbound lifetime will successfully promote itself to “only”
&'a &'a T if necessary to typecheck.
An unbound lifetime is produced whenever you:
- deref a raw ptr –
let ptr = &*raw_ptr;
- transmute to a ptr and don’t give an explicit lifetime –
Derefing a raw ptr is certainly inevitable transiently, and creating unbound lifetimes certainly has a practical use (e.g. this is used
split_at_mut). However I’m wondering if there are some limited scenarios where it could be linted against.
One trivial case is function signatures where output lifetimes don’t appear in inputs:
fn foo<'a>() -> &'a str
If you write this you’re pretty much always wrong – especially if you’re marking it as safe! In the past we’ve had std-lib errors of this form deriving from unbound lifetimes in struct definitions, and they were promoted to an error-by-default.