# Thread lifetime for TLS **URL:** \ **Category:** language design\ **Created:** [December 10, 2020, 9:53pm UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550 "2020-12-10T21:53:46Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![atagunov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/atagunov/32/5877_2.png) [@atagunov](https://internals.rust-lang.org/u/atagunov)\ **Post date:** [December 27, 2020, 7:40pm UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550/21 "2020-12-27T19:40:31Z")
> [@cuviper](#): > > I expect many would also get it wrong. The traits are `unsafe` for a reason, and being automatic means users don't have to understand that aspect to start threading their code. Some syntax could probably exist to opt in to making the knowledge of your `struct` being `Send` accessible from outside your crate such that using it on a non-`Send` struct would cause a compilation error. I'm still interested though if there are cases - either actual or proposed - when not propagating the knowledge of some `struct` implementing an auto trait outside of the `struct`'s crate would cause major trouble. ---
**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\ **Post date:** [December 27, 2020, 8:28pm UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550/22 "2020-12-27T20:28:00Z")
Most of the time, traits (auto or not) just enable more functionality, so missing them is just a limitation, not unsound. Marker traits can be used for `unsafe` assumptions, but I don't know any in the standard library that do unsafe things on the _lack_ of a trait. Sometimes auto-traits are used for compiler functionality, like the internal [`auto trait Freeze`](https://github.com/rust-lang/rust/blob/76188b6830897a875a1289809c12b5c5d69bb7ef/library/core/src/marker.rs#L716), but even missing that just means we would miss a lot of optimizations, yet still be sound, as unnecessary `!Freeze` would be pessimistic. ---
**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\ **Post date:** [December 28, 2020, 3:29pm UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550/23 "2020-12-28T15:29:58Z")
> [@cuviper](#): > > but I don't know any in the standard library that do unsafe things on the _lack_ of a trait. `Pin` does things like that, which is what caused [`Pin` is unsound due to rogue Deref/DerefMut implementations · Issue #66544 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/66544) (but that wasn't about an auto trait). ---
**Author:** ![jgarvin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jgarvin/32/5329_2.png) [@jgarvin](https://internals.rust-lang.org/u/jgarvin)\ **Post date:** [December 30, 2020, 12:45am UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550/24 "2020-12-30T00:45:25Z")
I think in the world we are imagining, you would manually opt into Sync and Send for your top level crate types, but the compiler would complain and force you to use the unsafe keyword if your type didn't completely consist of types that already satisfy those traits. The idea is to opt into the automatic propagation, not trusting the user. That would still require unsafe. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 30, 2021, 12:45am UTC](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550/25 "2021-03-30T00:45:27Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. [Previous page](https://internals.rust-lang.org/t/thread-lifetime-for-tls/13550.md?page=1)