3 ms·
> There’s still a tiny bit of unsafe floating around various dependencies that we plan to remove throughout the 0.5 release cycle I'd love to see what these us
by swsieber 3y ago
> There’s still a tiny bit of unsafe floating around various dependencies that we plan to remove throughout the 0.5 release cycle
I'd love to see what these usages are, and what motivates this. I understand that sometimes people reach for unsafe too eagerly. But the std is full of unsafe and drawing the line there sometimes seems like a line in the sand.
- jkelleyrtp 3y agoIt's mostly just needed to interact with FFI and declare some types as Send/Sync. We use it in 3 places: - fixing some FFI on iOS - enabling function-call syntax for signals (took this implementation from dtolnay) - implementing Send/Sync for an ID that uses a pointer as a hash (which honestly could be removed in lieu of a usize, now that I'm looking at it)
- swsieber 3y agoOh, OK. That sounds more like stuff you're directly responsible for, and it looks sensible.
- n42 3y agoI agree, people can be a little too afraid of unsafe. but I don't think it's necessarily ill-advised for a crate author to make a goal of removing unsafe from their crate. crate authors that try to remove all unsafe often do it to relieve the burden of trust from the user. _this_, in my opinion, is the power of the `unsafe` keyword (which probably should have been split into `trust_me` blocks and `check_yourself` functions). it constrains the conversations about memory safety into very tightly defined and auditable locations in the code, AND it creates new, manageable conversations about trust.