Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



It'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)


Oh, OK. That sounds more like stuff you're directly responsible for, and it looks sensible.


I 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: