I don't see how it's a misconception to say that a 'static lifetime lives for the life of the program. The author says "it can live arbitrarily long", which by definition must include... the life of the program. Where exactly is the error then?
> Well yes, but a type with a 'static lifetime is different from a type bounded by a 'static lifetime. The latter can be dynamically allocated at run-time, can be safely and freely mutated, can be dropped, and can live for arbitrary durations.
A 'static lifetime does not live for the rest of the program. It rather is guaranteed to live for as long as anyone is able to observe it. Data allocated in an Rc for example, lives as long as there are references to it. The ref count will keep it alive, but it will in fact still be deallocated once all references are gone (and it cannot be observed anymore).
I think if the compiler determines that it can drop a 'static, because nothing uses it after a certain point, it may drop it.
"life of the program" might imply it needs to begin life at program start. But it can be allocated at runtime, like an example in the list shows. So its rather "lives until the end of the program", but it doesnt need to start life at the start of the program
"Arbitrarily long" means "however long any code needs it to live", not "whatever lifetime a human reading the code can conceive of".
Because something with 'static lifetime does not in fact live for the entire program.
It just means that it could live until the end of the program and that case should be considered when dealing with it, there's no guarantee that it will drop earlier. But it may drop at any time, as long as there are no remaining references to it, it does not need to be in memory forever.
It's a subtle distinction and it is easy to misinterpret. For instance Tokio tasks are 'static and it felt wrong initially because I thought it would never drop them and leak memory. But it just means that it doesn't know when they will be dropped and it cannot make any promises about it., that's all.