The documentation for with is a bit ambiguous, but looking at the source it should always panic if the key has been destroyed. Since we return a reference, it can't escape its scope and so HANDLE won't be destroyed while it exists. Hence, this seems safe (but I could be wrong of course).

It's unsafe because this function allows you to obtain a &'static Handle reference and then use it even after HANDLE gets destroyed, without any additional checks.

@Vtec234 Destruction in the context of TLS is somewhat different than destruction in the rest of Rust unfortunately. When a thread exits, all of the registered TLS variables get destroyed - it doesn't have to do with scope. The problem arises when the Drop implementation for a TLS variable accesses another TLS variable which has already been dropped. @ezrosent and I have run into this issue, for example, when our own allocator caches (stored in TLS) were dropped after Crossbeam's TLS was dropped, but we relied on Crossbeam in order to implement Drop.

In that case another option would be to forward with and expose something like with_default_handle<F: FnOnce(&Handle) -> R>(f: F) -> R.

That's true, but that might lead to callback spaghetti. It's just as easy to do default_handle() -> Option<&Handle>, and somewhat more ergonomic.

And what's the issue with lifetimes when returning Option<&Handle>? Or is the lifetime problem only an issue when returning Option<Handle> (ie, not a reference)?

@joshlf: Without a lifetime-binding argument (like in with) the lifetime of &Handle will have to be 'static, and that can in turn be leaked until after the TLS drops since Rust allows passing 'static references around freely.

Ah I see. Fair enough.

A problem with fn default_handle() -> Option<&Handle> is we cannot implement it in Rust stable. I think we need to use HANDLE.try_with(), which is provided only in Rust nightly.

Ah good point. Would you guys be cool with just having it be feature-gated on nightly?