Effect system for panics and transitive unsafe

2

I'm against further demonizing unsafe.

  • It has a very very narrow scope as a security feature, because "safe" Rust can still execute arbitrary code (e.g. via Command, fs::write, or #[no_mangle] hacks). There's no sandbox, and no security in the language, so it could be giving false sense of security.

  • Wholesale bans on it are a strong disincentive to use unsafe in cases where it's entirely safe and necessary. This will force library authors to write weird and inefficient code in order to stay relevant to both trusting and distrusting fragments of the Rust userbase.

  • Ability to individually add exceptions for crates trusted with use of unsafe is both ineffective and collectively a massive waste of time for the Rust userbase. Rust projects use use lots of crates, so you can't expect users to honestly review every crate, so most likely they'll just whitelist based on a hunch. Even if users reviewed crates, doing so individually by every user is a huge duplication of effort.

So the overall problem "is this code bad?", "can I trust this author/crate?" is deeper than just presence of one keyword. I think it could be solved better, with fewer side effects, and with less overall effort required from Rust users by having shared crate reviews.

9 Likes