#send-sync #force #compiler

force-send-sync

Unsafe wrappers to force Send and Sync

2 stable releases

1.1.0 Jun 23, 2023
1.0.0 Nov 18, 2020

#226 in Programming languages

Download history 12954/week @ 2024-07-25 11921/week @ 2024-08-01 10559/week @ 2024-08-08 13751/week @ 2024-08-15 13417/week @ 2024-08-22 7963/week @ 2024-08-29 11850/week @ 2024-09-05 14883/week @ 2024-09-12 10312/week @ 2024-09-19 11992/week @ 2024-09-26 12159/week @ 2024-10-03 11295/week @ 2024-10-10 9829/week @ 2024-10-17 13628/week @ 2024-10-24 7627/week @ 2024-10-31 6290/week @ 2024-11-07

39,244 downloads per month
Used in 21 crates (5 directly)

MIT license

5KB
68 lines

Force Send Sync

Tells the compiler things are Send and/or Sync.

Reasons not to use this crate

If you should not know what Send and Sync means this crate is likely not what you are looking for. Usecases for this are extremly rare. This crate is unlikely to solve your problem and much more likely to turn the problem you have into a much messier one.

Reasons to use this crate

  • You have a type which Send and/or Sync but the compiler does not know it. Further you can not implement these yourself, because the code lives Upstream (maybe you could contribute there?).
  • You have a really weird situation there safety of these depends on configuration read at runtime and you need a way to promote safety of types.

lib.rs:

Please do not use this crate. The Rust compiler tries to protect you for a reason. Do under no circumstances use this to silence some compiler error you do not understand. Only use this if you do understand why your type is Send and or Sync, and also understand why the compiler disagrees with you.

No runtime deps