3 ms·

A lot of people don't seem to agree with me but I think even expect is too long of a name and terseness for commonly used names seems more important to me than

• Manishearth 10y ago
  You shouldn't really be using expect much :)
  • cgag 10y ago
    It's true I use and see unwrap more.
    • Manishearth 10y ago
      That's not good either :| unwrap should be confined to test and temporary code. It somewhat makes sense in example code, but expect is better for that. There are sometimes cases when you very easily know that the unwrap will never fail and if it does something has gone very horribly wrong, in which case you might use it. Libraries should keep usage of unwrap/expect to a minimum. Applications can be more liberal with it, but they should try to use expect or better error handling. Not everyone perfectly follows this, sadly. But most do.
      • pygy_ 10y ago
        It's at least partly a matter of affordance. You could soft-deprecate .unwrap() and .expect() (emit warnings at compile time, it will be annoying but not fatal), and provide a new version of expect with a name that's more cumbersome to type (or_panic_with(...) isn't bad in that regard, but you could do even worse... or_panic_with_error_message(...) :-).
• ben0x539 10y ago
  I don't think terseness helps much here, isn't the actual error message gonna dwarf the name of the method it's passed to in almost all scenarios?