`Component: Sync` (might be) too strict.

[DJMcNab]

What problem does this solve or what need does it fill?

Our requirements are too strict. This stops us from using types which are Send but not Sync in components, such as Cell<T>.

What solution would you like?

Remove the bound of Sync on component, and audit all the methods of World to ensure that any which go from &World->&T require T: Sync (primarily the SystemParam impl for &'_ T).

Note that the impl for &'_ mut T would not require Sync, since we guarantee that this reference is only on one thread (since the resultant Mut<T> can be used to get an &mut T directly).

What alternative(s) have you considered?

Keep things as they are - we haven't had a need for this yet, and it seems unlikely that we ever will.

However, philosophically there's no reason to have these bounds, and it strictly increases our usefulness.

Additional context

https://doc.rust-lang.org/nomicon/send-and-sync.html

https://doc.rust-lang.org/std/marker/trait.Sync.html

[DJMcNab]

So we've done a review of uses of NonSend, and failed to find a use of it where T: !Send - so this might be usable to 'parallelise' current uses of NonSend.

[alice-i-cecile]

I would be happy to see a PR tackling this: I think that weakening trait bounds like this is generally good hygiene.

[btrepp]

I've run into this using a linear type pattern for a state machine. The statemachine API doesn't really support borrows. Everything is moved.

When integrating with bevy, I realized the state machine needs to implement sync (send is still logical) but doesn't. So I either need to change my data structure to make bevy happy, or put it in a mutex to make bevy happy :).

[harudagondi]

When integrating with bevy, I realized the state machine needs to implement sync (send is still logical) but doesn't. So I either need to change my data structure to make bevy happy, or put it in a mutex to make bevy happy :).

In your case, bevy main has SyncCell which is Exclusive in nightly. Perhaps this may be useful to you.

[james7132]

This is partially addressed via #6864, which makes it a user-facing problem instead of one solved by bevy_ecs itself. Though it forces mutable access which may not be conducive to UX, especially regarding change detection.

[DJMcNab]

I agree that this is a capability we can get from composability.