5 ms·
"<...> but I don’t understand why I need to write code for both cases, error and success, when I only need value from successful case and I can completely ignor
by sjustinas 11y ago
"<...> but I don’t understand why I need to write code for both cases, error and success, when I only need value from successful case and I can completely ignore Err or None results."
Have you considered `if let`? Seems like the exact thing you need here.
https://doc.rust-lang.org/book/if-let.html https://doc.rust-lang.org/book/if-let.html
- EugeneOZ 11y agoOops, it's exactly what I need. Thank you very much, I'll strike out this text in article.
- oconnor663 11y agoThe Result type also has a bunch of methods like `map` and `and_then` that you can use to write code against only the success case. Take a look at https://doc.rust-lang.org/std/result/enum.Result.html https://doc.rust-lang.org/std/result/enum.Result.html
- yawaramin 11y agoSee also https://www.reddit.com/r/rust/comments/3h4u4v/take_advantage_of_iteration_syntax_to_act_on/ https://www.reddit.com/r/rust/comments/3h4u4v/take_advantage...
- CuriousSkeptic 11y agoThat page illustrates an important distinction between expression based languages and procedural ones. You couldn't do that in an expression, as it wouldn't type check without a value for the None case. When I first saw Option it seems like a great way to force handling of the None case, either explicitly in place, or by passing on a mapped option as a return value (monadic composition make this a nice thing). This resembles how exceptions are handled in most procedural languages, either you catch it and handle it, or you don't, and someone else gets to do it further up the call stack. The example on that page looks like the equivalent of an empty catch block. It's almost certainly a bad idea that will bite you in the ass some day.
- tpush 11y agoMaybe I'm misunderstanding you, but why wouldn't it work in an expression based language? Isn't if let pat = expr1 { expr2 } just syntactic sugar for match expr1 { pat => { expr2 } _ => { } meaning the type of expr2 must be unit, and thusly if let is always of unit type?
- CuriousSkeptic 11y agoGranted. But a unit expression is only useful for its side effect so I guess I put that in the gray area between paradigms, not really in the spirit of only evaluating expressions. Which brings us back the point of my comment: It's almost certainly a bad idea.
- sedatk 11y agoThe unhandled case is explicitly mentioned in the latter though.
- masklinn 11y ago> You couldn't do that in an expression, as it wouldn't type check without a value for the None case. Of course you could. If there is no `else` (which there can be, fwiw, just as the else case is optional in a regular if/else expression), the value of the None case is Unit: http://is.gd/Zdgc3D http://is.gd/Zdgc3D
- tatterdemalion 11y agoThis is not accurate. Rust is an expression based language, and `if let`s are expressions. If an `if` or `if let` returns (), it does not need an else.
- masklinn 11y ago> Rust is an expression based language I initially considered writing that, but it depends on what the original poster means by "expression-based language" and they haven't made that clear: in Rust, a function is a sequence of statements. An assignment is a statement for instance, not an expression. To me an expression-based language is something like Haskell or Elm, not only do you have ubiquitous expressions (which Rust does have) there's really no such thing as a statement, a program (or function) simply is an expression (possibly with multiple components) this Rust: let a = 1; let b = 2; a + b is 3 statements. The equivalent Elm or Haskell is a single expression: let a = 1 b = 2 in a + b