Post 9iF5tiDwTDBaVBLUWW by bugaevc@mastodon.technology
 (DIR) More posts by bugaevc@mastodon.technology
 (DIR) Post #9iF5LyHUGOzYSMumbg by codesections@fosstodon.org
       2019-04-27T19:25:29Z
       
       0 likes, 0 repeats
       
       #rust style preference question:When you have code that can't possibly fail but that returns an Option or a Result (for example `"5".parse::<i32>`), do you tend to use a bare `unwrap()` or switch over to `expect()` even when the infallibility seems obvious?
       
 (DIR) Post #9iF5fg0NvFP1ZCJNbc by emsenn@tenforward.social
       2019-04-27T19:29:02Z
       
       0 likes, 0 repeats
       
       @codesections not knowing rust i'd say the latter because i'm more likely to be using the latter in other places across the code so it'd be more stylistically consistent of code, if not the theoretically "best" function calls.Maybe this answer is bad because I don't know Rust, or maybe it's uniquely useful because I don't, hopefully that one!
       
 (DIR) Post #9iF5k8bTXL49Q9mtjk by musicmatze@mastodon.technology
       2019-04-27T19:29:50Z
       
       0 likes, 0 repeats
       
       @codesections never ever use functionality that could panic in library crates.Like... NEVER.That's my motto. I would return Result here. Really.
       
 (DIR) Post #9iF5tiDwTDBaVBLUWW by bugaevc@mastodon.technology
       2019-04-27T19:31:30Z
       
       0 likes, 0 repeats
       
       @codesections myself, I use .unwrap(), but I've seen code bases with explicit policy to *always* use .expect() with an explicit proof in the string, such as.expect("5, a hardcoded string constant, is a valid i32, therefore this conversion should not fail, QED")
       
 (DIR) Post #9iF7FeiMIZdrwVbGQi by codesections@fosstodon.org
       2019-04-27T19:46:42Z
       
       0 likes, 0 repeats
       
       @bugaevc > I use .unwrap(), but I've seen code bases with explicit policy to *always* use .expect() with an explicit proof in the string,Yeah, I've seen guidance like that too. > .expect("5, a hardcoded string constant, is a valid i32, therefore this conversion should not fail, QED")I'm torn between admiring the thoroughness there and hating the verbosity.
       
 (DIR) Post #9iF7NoTdswWiXObek4 by codesections@fosstodon.org
       2019-04-27T19:48:15Z
       
       0 likes, 0 repeats
       
       @musicmatze That's fair.  But even if it's just in a binary crate, you (or someone) has to get at underlying values *some* of the time.
       
 (DIR) Post #9iF7naUGWQWqg5BiZU by bugaevc@mastodon.technology
       2019-04-27T19:52:53Z
       
       0 likes, 0 repeats
       
       @codesections I guess it depends on the level of assurance you're aiming for. Rust is about writing reliable (& fast) programs, and any kind of program would benefit from reliability/stability, and yet different kinds of programs require different levels of it. If it's mission-critical software, you can tolerate the verbosity.
       
 (DIR) Post #9iFF5BaOXewoL8OSrQ by jack@mastodon.allnutt.net
       2019-04-27T21:13:57Z
       
       0 likes, 0 repeats
       
       @codesections There's also the unreachable crate, which provides unchecked unwrapping (for performance sensitive code)https://crates.io/crates/unreachable
       
 (DIR) Post #9iFNkb7PJhvB295nea by federicomena@mstdn.mx
       2019-04-27T22:51:36Z
       
       0 likes, 0 repeats
       
       @codesections mostly unwrap(), unless there's some environmental thing that may make it fail and then expect() provides a hint to whoever has to debug it.