I found this immensely helpful as someone going through the book and not completely understanding Send & Sync! Thanks for this unique perspective, great talk!
@@johnsmith34 the rules she talks about regarding "send" it reminds me of ownership rules but different thus I think thay can be an expansion to the ownership rules and the compiler should enforce those as well
The compiler will automatically infer Send and Sync correctly for structs and enums on the assumption that no unsafe code depends on the content of those types. If you're using unsafe to write your own concurrent data structures / mutexes / etc, then it's not possible for the compiler to check the unsafe code in general. In some cases it should be possible to check these conditions with Miri, but not in the general case (and probably not efficiently either). As long as you're not writing unsafe code, you shouldn't have to worry about checking these rules, but understanding them is useful so that you know when you can use what types.
The rules are all enforced, one way or the other, if that's what you're asking. AFAIK, the following things work together to provide this enforcement: 1. the borrow checker 2. trait bounds on certain functions/methods, e.g. ones that make a value visible to another thread 3. the compiler's rules for deciding whether a new type is Sync and/or Send, based on whether its component types are 4. the Sync and Send status of std types As usual, you can get around this in unsafe code, e.g. by providing an unsafe impl for Sync for a type, if you know what you are doing. But there be dragons.
