Visibility and existence are different
Scope concerns where a name can be used in code; lifetime concerns an object’s existence during execution. Leaving a local binding’s scope can trigger cleanup, while another management mechanism can keep a shared object alive.
Conversely, retaining a variable containing a pointer or reference does not ensure that its referent remains valid. The value can remain in a program after storage release or after the conditions for accessing the former object have ceased to hold.
Lifetime annotations describe relationships
Rust lifetime parameters express constraints among reference validities. A function returning one of two string slices must relate its result to the inputs so callers use it only within the required common valid range.
Annotations do not change how long an input actually exists or revive an expired local value. Returning a reference to a local String remains invalid. Transferring an owned String is a different way to provide the caller with the value.
Cleanup follows specified language rules
Rust associates variables and temporaries with drop scopes and specifies cleanup order. Struct fields and local variables follow their respective rules; a remaining address does not override ownership and destruction behavior.
Automatic cleanup has boundaries. Rust permits explicit suppression of destruction and process termination without unwinding. Those cases do not provide ordinary scope-exit cleanup. Valid object access, resource leakage, and termination behavior are separate properties.