I composed a finite state automaton for the subject to better understand it. My interpretation of the rules is: if T implements Sync and doesn't implement Send and F is a non-empty composition of type constructors & and &mut, then F<T> implements Send iff the finite state automaton below accepts F (…

I think trying to see these rules as a finite state machine just makes them harder to understand. Instead I would suggest you to look at the individual rules for when Send and Sync are implemented respectively for &T and &mut T: &T implements Sync when T implements Sync because sharing a &T only r…

Hi, Send and Sync is a complex topic if you want to understand it thoroughly. Your FSA seems to be about the Send & Sync implementations of &T and &mut T. If you start out with T: Sync and build up some nested type like &mut &mut T or &mut & &mut & &mut T or whatever, then your FSA seems accurate. …

Why these particular rules for `Send`, `Sync`, and borrowing references?

help

quinedot January 6, 2025, 8:01pm 4

Here's another overview of Send and Sync.

Topic		Replies	Views
Why is a `&mut` references to a `Send` type not automatically `Sync`?	29	2359	September 4, 2023
Why impl Sync for Mutex requires T: Send help	19	4768	June 14, 2022
How can a MutexGuard possibly be Sync? help	24	1419	June 12, 2024
Where is the place that implements the trait Sync for "& mut T"? help	18	1385	December 29, 2022
Send without Sync is possible? help	10	4259	August 21, 2019

Why these particular rules for `Send`, `Sync`, and borrowing references?

Related topics