4 ms·

I think the idea is to fail to compile if you have certain kinds of panic? I agree that making unwrap/expect silently ... not happen will just cause worse prob

I think the idea is to fail to compile if you have certain kinds of panic? I agree that making unwrap/expect silently ... not happen will just cause worse problems.

wyldfire 10y ago
Sure, but in that case it would effectively elide it from the language spec! Who doesn't target "production" eventually?
- 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 ago
    Yes, 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 ago
      This 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
- kzrdude 10y ago
  Early exploration and tests amount to a lot of code, and the language needs to make those parts pleasant to write as well. I think .unwraps() are especially common there. I imagine `println!()` is another thing whose design is influenced by meeting the needs of early exploration implementations (and it's another example of a library function that handles errors with panics, for example, but it's not just the thing that makes me think so).

I think the idea is to fail to compile if you have certain kinds of panic? I agree that making unwrap/expect silently ... not happen will just cause worse problems.

wyldfire 10y ago

Sure, but in that case it would effectively elide it from the language spec! Who doesn't target "production" eventually?

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 ago
  Yes, 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 ago
    This 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
kzrdude 10y ago
Early exploration and tests amount to a lot of code, and the language needs to make those parts pleasant to write as well. I think .unwraps() are especially common there. I imagine `println!()` is another thing whose design is influenced by meeting the needs of early exploration implementations (and it's another example of a library function that handles errors with panics, for example, but it's not just the thing that makes me think so).