3 ms·
> Sure, but in that case it would effectively elide it from the language spec! No. Some unwraps are necessary. You wouldn't be absolutist here; you could still
by Manishearth 10y ago
> Sure, but in that case it would effectively elide it from the language spec!
No. Some unwraps are necessary. You wouldn't be absolutist here; you could still allow some carefully-labeled unwraps.
Also, not all production users need to care about panics that much.
- tmzt 10y agoYes, I would envision an allow attribute of some sort. This is simply a contract with compiler that you didn't copy and paste some example code somewhere in your codebase that fails with an unwrap. It's about extending the "if it compiles it runs" near-guarantee that we so love about Rust. Ideally a program would fail fast and be restarted if it reached an unrecoverable state, with supervision trees like Erlang. Also ideally, unwrap would be used for exceptional states, not only ones that are unlikely to fail until something goes wrong, like a port being closed or a file unreadble or not present.
- Manishearth 10y agoThis is basically what https://github.com/Manishearth/rust-clippy/wiki#option_unwrap_used https://github.com/Manishearth/rust-clippy/wiki#option_unwra... does It doesn't work transitively (so if a crate you depend on unwraps you can't protect yourself), but https://github.com/llogiq/metacollect https://github.com/llogiq/metacollect plans to fix that