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.
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, but even missing that just means we would miss a lot of optimizations, yet still be sound, as unnecessary !Freeze would be pessimistic.
Pin does things like that, which is what caused `Pin` is unsound due to rogue Deref/DerefMut implementations · Issue #66544 · rust-lang/rust · GitHub (but that wasn't about an auto trait).
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.